Sonatype

×

Baselining Your Component Usage


Risk

Let’s talk about risk. You’re probably reading this guide to find out how to remove some, if not all, of the risk from your product. Specifically risk in your software application that comes from open source software components. But your software, even software built from scratch, will have some risk. Problems from open source components like security vulnerabilities, license restrictions, and quality issues can be troublesome  to read about, especially with high profile breaches like SolarWinds and Equifax. But the benefits of OSS far outweigh the risks when you manage your software correctly.

Open source packages save your developers tremendous amounts of time by letting them focus on solving the challenges unique to your application and can provide thoughtful, thoroughly tested solutions to complex problems for free.

Establishing a Baseline

Since risk is inevitable, the solution isn’t to try and eliminate risk but to manage it. To do that, you will need to establish a baseline of what risk already exists. Once you know that benchmark, you can define a set of rules defining what risk is acceptable and what isn’t. This is your organization’s risk tolerance. It will vary from project to project and from organization to organization. Once you decide what risks are acceptable for your project, you can make informed decisions about your risk level while still innovating quickly.

A common pattern when teams adopt scanning tools is to scan an application then try to remove all the vulnerabilities their Software Composition Analysis (SCA) tool finds.

Here’s how to approach establishing your risk baseline: 

Identify the components in your application.

The best way to do this is to generate a software bill of materials or SBOM. An SBOM lists every component in your application and their relationship to other components in a standard format that can be read easily by both humans and computers. The two SBOM standards are CycloneDX and SDPX. CycloneDX is our recommendation since it’s developed specifically for monitoring security vulnerabilities.

The software bill of materials is the first step in managing your risk from open source packages since it gives you a way to identify the applications you’re actually using, including packages brought in from your dependencies. This report can be used with software composition analysis tools to generate a report on your vulnerability information, shared with customers for assessment, and used to monitor your application for new dependencies.

Eventually you should create a vulnerability exploitability exchange and connect it with your software bill of materials. This companion document lets you track security vulnerabilities in your application and indicate when possible vulnerabilities do not apply to your implementation of the package.

Identify the risk from your existing components.

Once you know what you’re using, the next step to managing your risk is to identify your existing risk. The best way to do this is by using a software composition analysis tool. SCA Tools can automatically determine which components you’re using and then check their available vulnerability databases to give you detailed information on the potential risks from your dependencies. The best tools will check your project’s build artifacts against public and proprietary information sources to determine potential risks, while others will check the application manifest file or SBOM against publicly available data.
SCA Tools:

    • Nexus Lifecycle
    • OSS Index
    • OWASP Dependency Check

Decide if anything needs to be remediated.

Deciding what to remediate when you start managing your open source risk is tricky. Rarely do you want to go back and remove all of your existing risk, especially in older applications and large codebases. A common approach is to accept all but the most severe risks. Remediation takes time away from developing your applications. Redoing existing work can frustrate your development teams and take attention away from the processes of proactively managing risk moving forward. Any extreme vulnerabilities, like easy-to-exploit, remote code execution, should be addressed as these represent a huge danger to your organization and potentially your users. 

Moving Forward

The goal with open source risk management is to innovate as fast as possible without taking unnecessary risks. Oftentimes, your existing applications won’t completely meet the open source governance policies your organization has adopted. This is a compromise, but it allows your company’s focus to be on newly emerging, active risk rather than removing existing risk that might simultaneously create more risk. This proactive approach will ensure that your future projects will be less risky through proactive risk mitigation. 

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments