The following best practices are guidelines to consider when starting your remediation efforts.
Empower your developers with these principles to improve outcomes:
Prioritize remediation of the least effort violations
Provide documented instructions/workflows for common scenarios
Avoid creating noisy violations which will be deprioritized and ignored
Give teams time to fix issues with reasonable expectations
Invest in the open-source projects you depend on
Instill good component hygiene practices
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.
Working closely with a pilot team will help you improve your onboarding guidance
Watching a pilot team will also help you form reasonable expectations
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
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
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
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
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
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 component and application views to view areas with the highest risk
Keep an eye on new violations by regularly checking the dashboard
Automatically filing tickets or sending notifications is more useful once developers have a case to reduce risk
Treat resolving OSS violations as important as addressing technical debt
Set clear goals with reasonable expectations for resolving violations
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
Focus on upgrading direct dependencies before transitive dependencies
Upgrading direct dependency will often resolve issues with transitive dependencies they brought in
Transitive dependencies are the components your direct dependencies need
To fix violations against transitive, upgrade your direct dependencies
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
Good OSS components have low MTTR for critical vulnerabilities
Being dependent on unpopular projects without active development can result in long-term technical debt
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
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
Misconfigured dependencies are some of the most common security issues
Avoid exposing open-source dependencies directly to unsanitized user inputs
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
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
Instruct your developers to add waivers to any issue they will not immediately address
Focus on new or critical issues to cut the noise
Waivers help your development teams manage risk by prioritizing what is important and deferring the issues that may be addressed later.
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
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
Consider allowing them to decide and create waivers they are accountable for
Be specific about what is an acceptable waiver and what information is required
Regularly audit waiver scope and details for accuracy