Creating a Lifecycle Remediation Plan
The Lifecycle solution is most effective when used for automatic discovery and remedation of risk with using open-source components in your application development. 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.
Audience
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 are more for Developers). However, everything here is informationally relevant to all roles.
Desired Outcomes
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.
Prerequisites
Remediation is an essential part of your risk reduction workflow. To get started, you will want to address the following:
Define your adoption model. This is how applications and organizations are added to the IQ Server.
Identify application categories pertinent to your organization. Application categories provide a way to prioritize the risk characteristics of an application and set specific policies for them.
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.
Evaluate your applications. In order to remediate risk, you need to know what’s in your applications. We recommended getting a baseline of all your applications by integrating a scan in the build process, or by onboarding through your SCM. You can also run one-off scans in the UI or CLI.
Importance of Remediation
After Lifecycle is set up and you’ve started scanning, it is easy to be inundated with results. The 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 Lifecycle 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. Lifecycle 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 Lifecycle 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 who provide input when creating policies.
Organizational Role | Responsibilities |
|---|---|
Open Source | Define community policy |
Legal | Define legal/licensing policy |
Security | Define security policy |
Architecture | Define architecture policy |
Integration Participants. The primary responsibility here is to integrate Lifecycle into your release process.
Organizational Role | Responsibilities |
|---|---|
Build Engineer/Devops | Integrates Lifecycle into build and release jobs |
Dev Manager | Balances priorities between fixing security issues and functionality to deliver |
Operations | Install, maintain, and deploy Lifecycle |
IQ Server Participants. These are people in your organization who will interact with Lifecycle the most, doing the day-to-day operations.
Organizational Role | Responsibilities |
|---|---|
Project Sponsor | Bring in Lifecycle and get everyone on board |
Project Owner | Triage findings and apply waivers |
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 May 30th”
Set a date for enforcement. For example, “Warn on builds in release for CVSS > 5 until July 30th 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 June 30th.”
Set a date to establish remediation workflows. For example, “Remediation workflows in place for new issues by May 30th.”
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 the CVSS score and your risk management threat analysis. It is then up to the developer to follow the applicable workflows and remediate the risk.
Prioritization
Analyzing findings and creating actionable tasks can be daunting. Fortunately, Lifecycle has several features available to help prioritize results.
Waivers
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 exploitation. 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 for 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).
Component Labels
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.
Legacy Violations
Prioritizing the large volume of violations often found in legacy applications can be difficult when first onboarding applications to Lifecycle. The Legacy Violations feature lets you distinguish remediation for newly discovered risk while managing a backlog of existing violations — those that existed before Lifecycle was adopted. Legacy Violations won’t cause a policy action (for example fail the build), while newly discovered violations will.
Notify Your Team
Once fixes have been prioritized, it’s important to notify your team of the findings. Lifecycle has various ways to set up alerts through things like JIRA integration, email, messenger, CI, and webhooks.
JIRA Integration
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 a Lifecycle analysis report into your organization’s development process.
Email, Messenger, and CI Alerts
Lifecycle 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 a policy configured to notify them. Anyone receiving these alerts will see an overview of the violation with a link to the full results in the report.
Webhooks
Webhooks are a powerful feature that lets you receive notifications about events that happen in Lifecycle. Use webhooks for policy management, application evaluation, security vulnerability override management, and license override management events.
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 Lifecycle UI and also in 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.
The following chart represents a sample security remediation workflow:
Measure Your Progress
Sonatype Lifecycle 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 the Lifecycle solution. 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.
The Application Composition Report represents the health of your application. It serves as a point-in-time report representing security and license risks 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.
Finally, the Dashboard provides the quickest way to review the overall health of the 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.