In this guide:
- Importance of Remediation
- Make a Remediation Plan
- Review and Analyze Findings
- Notify Your Team
- Remediate and Reduce Security Risk
- Measure Your Progress
- [Additional Resources]((/iqserver/technical-guides/iq-security-remediation/#resources)
- Talk to Us
Remediating risk will let you get the most out of your Lifecycle solution. Creating a remediation process will help you reduce risk across your organization by resolving policy violations from scan reports and improving the quality of OSS components used by your applications.
This article will help you identify, and put in process, ideal research and remediation guidelines for your organization.
NOTE: This guide is written based on release 54 of the IQ Server. Some functionality described here may be different depending on the version you are using.
Sections of this guide may be more applicable to one role within your organization than another (i.e analyzing findings is geared toward Project Owners while remediation workflows is more for Developers). However, everything here is informationally relevant to all roles.
By the end of this guide you’ll be able to:
- Understand the importance and need for remediation.
- Have a plan to get started with remediation.
- View and understand some basic remediation workflow examples.
- Measure your progress with IQ Server reports.
Remediation is an essential part of your risk reduction workflow. To get starting, you will want to address the following:
- Define your adoption model. This is how applications and organizations are added to IQ Server. For more information please see our help docs on Hierarchy and Inheritance and Onboarding Applications.
- Identify application categories pertinent to your organization. Application categories provide a way to prioritize risk characteristics of an application and set specific policies to them. For more information, please see our help docs on Application Categories.
- Set up your governance policies. IQ Server comes with a set of predefined policies used by the majority of organizations. These should be evaluated and updated to align with your application security priorities to get an accurate baseline of risk. For more information, please see our help docs on Policy Management. These items are covered in detail during a Policy Workshop.
- Evaluate your applications. In order to remediate risk, you need to know what’s in your applications. We recommended get a baseline of all your applications by integrating an IQ scan in the build process, or by onboarding through your SCM. You can also run one-off scans in the UI or CLI. For more information, please see our help docs on Using the CLI with a CI Server, Manual Application Evaluation, or Evaluating Applications with the CLI.
Importance of Remediation
After IQ Server is setup and you’ve started scanning, it is easy to be inundated with results. Results of a scan can leave you with a lot of vulnerabilities that you need to deal with. You need to remediate to get the most out of IQ Server and reduce risk to your organization.
Putting a remediation plan in place helps you accomplish the following:
- Improved communication. You’ll have a clear understanding of your organization’s risk posture, remediation workflows, and responsible stakeholders.
- Better software. Improved component selection helps you build better, more secure software.
- More efficiency. Early identification allows you to continue to work, even when issues arise during development.
- Reduction of busy work. IQ Server delivers expert security information that lets you make informed decisions early, rather than at the end of a dev cycle.
While it’s good to understand the importance and need for remediation, you should also know that it is easy to get started remediating — especially if you have a plan in place.
Make a Remediation Plan
In this section, you’ll define organizational roles, set remediation goals, determine your risk management process, and then put together a plan to socialize adoption. The IQ Server project sponsor will drive most of the work described here.
Define Organizational Roles and Responsibilities
Everyone in your organization is responsible for security, although their responsibilities differ by role. Clearly defining who is in charge of what is a great place to start with your remediation plan. There are three types of participants that you should define:
Policy Creators. These are subject matter experts that provide input when creating policies.
|Open Source||Define IQ Server community policy|
|Legal||Define IQ Server legal/licensing policy|
|Security||Define IQ Server security policy|
|Architecture||Define IQ Server architecture policy|
Integration Participants. The primary responsibility here is to integrate IQ Server into your release process.
|Build Engineer/Devops||Integrates IQ Server into build and release jobs|
|Dev Manager||Balances priorities between fixing security issues and functionality to deliver|
|Operations||Installs, maintains, and deploys IQ Server|
IQ Server Participants. These are people in your organization who will interact with IQ Server the most, doing the day to day operations.
|Project Sponsor||Bring in IQ Server and get everyone on board|
|Project Owner||Triage findings and apply waivers - only person(s) that has authority to accept risk|
|Developer||Selects components and implements fixes|
Set Your Goals
The next step to remediation success is clearly defining your goals. It’s best to get input on your goals from the various stakeholders described above.
Some example goals for your Lifecycle remediation process could be:
- Measure your direction. For example, “Number of CVSS 5 reduced by 50%” or “Number of CVSS 5 reduced by 50%.”
- Set a date for a specific CVSS threat level threshold. For example, “No CVSS > 5 in operation as of 5/30/2019.”
- Set a date for enforcement. For example, “Warn on builds in release for CVSS > 5 until 7/30/2019 then fail after that date.”
- Set a date for issues in your SDLC tracking tool. For example, “Current issues in project backlogs and ready for sprint planning by 6/30/2019.”
- Set a date to establish remediation workflows. For example, “Remediation workflows in place for new issues by 5/30/2019.”
Keep in mind that your goals can change with time, and it’s a good practice to establish a cadence for when goals are reviewed (i.e. review and redefine goals 2x a year).
Get Everyone On Board
Security is everyone’s responsibility, and that’s why everyone should be on board. The more your plans are communicated and socialized, the better adoption you’ll have.
At Sonatype, we like to talk about “support and guide” rather than the “scan and scold” approach. Some ideas to get started with this adoption are:
- Establish communication channels for various stakeholders.
- Define the change request process for policy changes and waivers.
- Provide shared documentation as a wiki/guide letting folks know where to turn for help.
Review and Analyze Findings
Now that your plans are in place, the next step is for the Lifecycle Project Owner to take the report and prioritize your remediation process. The Lifecycle Project Owner is the one who analyzes scan reports and gets to actionable findings based on the defined organizational goals, the lifecycle of your application, and policy decisions set by the stakeholders. Developers will then apply fixes based on these findings.
In most cases, the remediation path is to upgrade to a patched version of the component. If a fixed version does not exist, or the risk of breaking API changes is too great, the Project Owner will need to manually evaluate the various types of risks that a security issue exposes. For example, the Project Owner may identify several types of security issues:
- Configuration: By default the component is configured to be insecure, and needs determination if there is a case for direct exploitation.
- Functional: Requires a specific function to be called.
- User Input: Requires specific user-controllable input.
- Test or Sample Code: Has sample or test code not normally included in an operational context.
- Operational: Effects runtime operational context, often affecting JVM’s, application servers, or runtime configurations.
Once issues are identified, the Project Owner determines the risk and associated remediation effort (i.e. technical debt vs. exploitation in the application) and identifies the immediacy of fixing based on CVSS score and your risk management threat analysis. It is then up to the developer to follow the applicable workflows and remediate the risk.
Analyzing findings and creating actionable tasks can be daunting. Fortunately, IQ Server has several features available to help with prioritize results.
When analyzing risk, you may come across situations where you determine the issue will not be fixed. For example, the cost of a fix may not be justified if there is a limited product life, or a low risk of exploit. In these cases, you may be left with a situation where there is no fix, or the issue doesn’t need to be fixed. These issues represent acceptable risk. In these cases, you may want to apply a waiver. If a waiver is needed, it’s best to give specific information (app ID it applies to, policy it’s violating, actual CVE involved, and why you’re waiving it — i.e., justification).
For more information on waivers, please see our help docs on Waivers.
Alternative to waivers, the use of component labels can be used for security issues. The function of labels is to provide metadata that you can assign to a component within the context of a particular application or organization. This can assist with identifying components you want to review, approve, or even avoid altogether. For example, you can use them to create and track blacklist or whitelist components and not waive policy, losing components in future scans. For more information on labels, please see our help docs on Component Labels.
Prioritizing the large volume of violations often found in legacy applications can be difficult when first on-boarding applications to Lifecycle. The grandfathering feature lets you distinguish remediation for newly discovered risk, while managing a backlog of existing violations — those that existed before Lifecycle was adopted. Existing grandfathered violations won’t cause a policy action (for example fail the build), while newly discovered violations will.
Grandfathering provides a route to automated enforcement when applications have a large backlog of existing issues. For more information on this feature, please see our Policy Violation Grandfathering help docs or the IQ Server Grandfathering technical guide.
Notify Your Team
Once fixes have been prioritized, it’s important to notify your team of the findings. IQ Server has various ways to set up alerts through things like JIRA integration, email, messenger, CI, and webhooks.
Configuring JIRA notifications will create an issue when new policy violations are discovered during the development process. This is an important step in automating the remediation workflow by integrating IQ Server analysis report into your organization’s development process. For help configuring this integration, please see our docs on JIRA Notifications.
Email, Messenger, and CI Alerts
The IQ Server can be configured to send email notifications for events such as policy violation notifications. Your operations team can also assist in setting up alerts for your messenger apps and Continuous Integration (CI) environments. These alerts are sent to anyone on your team that has policy configured to notify them. Anyone receiving these alerts will see an overview of the violation with a link to full results in the report.
Webhooks are a powerful feature that let you receive notifications about events that happen in IQ Server. IQ Server lets you use webhooks for policy management, application evaluation, security vulnerability override management, and license override management events.
For more information, please see the Webhooks topic in our IQ Server help docs.
Remediate and Reduce Security Risk
Now it’s time to start remediating based on your goals, review, analysis, and prioritization. Successful risk management is the process of identifying vulnerabilities and threats and then deciding what actions you can take to reduce those risks and reach your goals.
This next section will give you some example developer remediation workflows that can help you focus on how to lower risk. Remediating risk starts with improved component selection based on data. This data is generally found in the Component Information Panel or CIP, which is available from the IQ Server UI and also in of our IDE integrations. Information provided in the CIP helps developers investigate their choices and select better components based on newer available versions, most popular versions, and security and licensing issues.
In general, policy resolution can be achieved by completing one of the following tasks:
- Upgrade to a non-vulnerable version of the same component. This option is most recommended because it is generally the easiest path to resolution and reducing your risk.
- Migrate to a component that does not contain the violation. If you’re not able to upgrade your component, the next step is to migrate to a similar component without the violation. This option involves research, because you’re looking for a replacement component that provides the same functionality while ensuring it’s not exploitable.
- Request a waiver for the policy violation. If you can’t upgrade or migrate, the next option is to request a waiver. Send a waiver request to the Project Owner with enough information for a determination to be made. Applying a waiver assumes a certain amount of technical debt, and does not fix the violation. Because of this, it should be used judiciously.
Sample Resolution Order
When coming up with a developer remediation resolution workflow, it’s good to keep the following in mind:
- Policy Threat Level denotes the importance of an issue.
- Work through direct dependencies first.
- Resolve transitive dependencies last.
The following chart represents a sample issue resolution order:
In the above workflow, you’ll get to a point where developers should follow the issue type remediation workflow for the identified issue. Next, we’ll give you an example workflow that could be used for security remediation.
Sample Security Remediation Workflow
In this security example, if you can’t upgrade and refactor code, that means it’s time to research and see what you can do to mitigate your risk. For example, if the component is not exploitable you can use waivers or labels to denote the risk. If you can’t mitigate the risk, it’s time to start a risk management process. The purpose of a risk management plan is to identify acceptable risk thresholds and then document how those risks will be identified, qualified, quantified, and prioritized. For example, if you’re willing to accept the risk, you could mark it as acknowledged.
Measure Your Progress
Nexus IQ Server provides many ways that you can measure your remediation success:
- Success Metrics are high-level, executive reports that can help you demonstrate the value of IQ Server. Specifically, the Mean Time to Resolution (MTTR) by Month tile shows the average age of resolved violations for the last year. This information is further broken down by their threat level. For more information, please see our Success Metrics help docs.
- The Application Composition Report represents the health of your application. It serves as a point-in-time report representing security and license risk associated with component usage for a specific application. The report includes information on how the application complies with the policies your team, or business, has established. For more information, please see our Application Composition Report help docs.
- Finally, the Dashboard provides the quickest way to review the overall health of applications you manage. The Dashboard provides filters that let you view results by things like organization, violations found within a specific stage, or policy type. For more information, please see our IQ Server Dashboard help docs.
Talk to Us
And visit my.sonatype.com for all things Sonatype.