Remediation Best Practices

Introduction

The following best practices are guidelines to consider when starting your remediation efforts.
Empower your developers with these principles to improve outcomes:

1. Prioritize remediation of the least effort violations
2. Provide documented instructions/workflows for common scenarios
3. Avoid creating noisy violations which will be deprioritized and ignored
4. Give teams time to fix issues with reasonable expectations
5. Invest in the open-source projects you depend on
6. Instill good component hygiene practices

Baselining

Before breaking builds and sending out a wall of notifications, baseline your applications by getting an initial scan of applications in your SDLC. This can be done using the SCM onboarding tool or working through the CI scanners. Writing a shared library of scanning tools for your CI builds will allow you to make changes as your efforts mature.

Start with a pilot team

• Working closely with a pilot team will help you improve your onboarding guidance
• Watching a pilot team will also help you form reasonable expectations

Check your scanner configuration

• Misconfiguring scanners is a very common issue; take time to get this right before widely deploying
• If your reports are empty, you may not have the correct scan targets
• If you have many unknown components, use Innersource Insights and adjust your proprietary configuration

Review your policies and application categories

• Most License Policies are scoped to applications with the 'Distributed' category
• Set application categories or rescope the policy to all applications if license risk is important

Group your applications by those in active development versus legacy development

• Legacy applications often have the most issues and the least amount of funding to fix them
• Grouping out these environments makes it easier for some teams to work more quickly than others
• Improves reporting by making them more reflective on what is actionable

Make sure your application scans are actionable and targeted to the risk developers can manage

• Avoid making your developers responsible for code they don't manage, such as when scanning containers or multimodule projects
• Your developers should not be responsible for managing risk brought in by other teams and environments

Prioritization

When prioritizing violations, it is useful to follow the 80/20 rule. 80% of the violations take 20% of the time with the last 20% taking 80% of the time.

• Focus on quick wins while reducing noise
• Give development teams a chance to review scan reports
• Avoid blocking builds when there are a large number of violations to remediate
• Avoid filling up developer backlogs with OSS violation tickets

Use Recommended Remediation from the Component Details Page

• The recommendations will provide the next version upgrade without breaking changes and policy violations
• These should be relatively quick ways for your developers to reduce risk

Use the Dashboard to target problem applications or violations with the widest impact

• Use the component and application views to view areas with the highest risk
• Keep an eye on new violations by regularly checking the dashboard

Avoid sending notifications for non-critical issues

• Automatically filing tickets or sending notifications is more useful once developers have a case to reduce risk

Schedule time during the quarter to review and remediate OSS violations

• Treat resolving OSS violations as important as addressing technical debt
• Set clear goals with reasonable expectations for resolving violations

Waive violations that will not be addressed in the near term

• Leaving violations in the scan report will encourage teams to ignore them
• Use time-based waivers to schedule remediation efforts so that teams can address the issue

Remediation

Prioritize upgrading direct dependencies to non-vulnerable versions

• Focus on upgrading direct dependencies before transitive dependencies
• Upgrading direct dependency will often resolve issues with transitive dependencies they brought in

For transitive violations, update their direct dependency

• Transitive dependencies are the components your direct dependencies need
• To fix violations against transitive, upgrade your direct dependencies

Consider temporarily patching components where upgrading is not immediately available

• Good OSS projects will provide guidance to patch critical new vulnerabilities
• This should not be a longer-term solution, so regularly view any waivers for patched projects
• Replace patched components as soon as you can so you do not become locked to older versions of the dependency

Look for similar open-source components that do not have violations

• Good OSS components have low MTTR for critical vulnerabilities
• Being dependent on unpopular projects without active development can result in long-term technical debt

Mitigation

Remove any open-source dependencies that are not used

• OSS dependencies are often added to a project but never used
• Cleaning them from your application environment will go a long way to eliminating risk

Avoid including development dependencies with product applications

• Testing frameworks and developer tooling will often have resolved security issues as they are not meant to be deployed to production
• Avoid using developer tooling that has known critical risks

Restrict OSS risk by restricting their exposure in your code

• Misconfigured dependencies are some of the most common security issues
• Avoid exposing open-source dependencies directly to unsanitized user inputs

Consider using internal code instead of open-source dependencies

• Some non-critical dependencies are better to avoid and use your own code where possible
• Using a large number of dependencies can expose your application to unnecessary risk

Contribute to open-source projects you depend on

• Encourage your developers to participate in projects that are regularly used throughout your organization
• Budget time for your developers to contribute back to the open-source community
• Document clear guidelines for your developer to participate in open-source
• Celebrate the work your teams do with open-source projects

Use temporary waivers for violations that will not be prioritized

• Instruct your developers to add waivers to any issue they will not immediately address
• Focus on new or critical issues to cut the noise

Reviewing Risk

Waivers help your development teams manage risk by prioritizing what is important and deferring the issues that may be addressed later.

Using vulnerable components will continue to present risk even when your risk exposure is very narrow

• Developers may determine that a critical vulnerability is not an issue because of how the component is used or because the risk exposure is very narrow
• Even so, it is better to eventually plan to change components as environmental factors may change in unexpected ways
• Most often, the component is still a risk by remaining in your application

Always use time-based waivers

• Waivers should be regularly audited to make sure they are still applicable
• Make sure every waiver is set to expire or plan to manually review all waivers at least once a year
• Make sure your developers include enough details on the waiver to validate the claim that the risk is not applicable

Empower your developers to own their open-source risk

• Consider allowing them to decide and create waivers they are accountable for

Document a common format for waivers so they are understood and accountable

• Be specific about what is an acceptable waiver and what information is required
• Regularly audit waiver scope and details for accuracy