The previous 12 months has seen an industry-wide effort to embrace Software program Payments of Supplies (SBOMs)—a listing of all of the elements, libraries, and modules which can be required to construct a chunk of software program. Within the wake of the 2021 Government Order on Cybersecurity, these ingredient labels for software program turned common as a strategy to perceive what’s within the software program all of us devour. The guiding thought is that it’s unattainable to evaluate the dangers of specific software program with out understanding all of its elements—together with these produced by others. This elevated curiosity in SBOMs noticed one other enhance after the Nationwide Institute of Requirements and Know-how (NIST) launched its Safe Software program Growth Framework, which requires SBOM info to be out there for software program. However now that the {industry} is making progress on strategies to generate and share SBOMs, what can we do with them?
Producing an SBOM is just one half of the story. As soon as an SBOM is on the market for a given piece of software program, it must be mapped onto a listing of identified vulnerabilities to know which elements might pose a risk. By connecting these two sources of knowledge, shoppers will know not simply what’s of their software program, but in addition its dangers and whether or not they should remediate any points.
On this weblog publish, we reveal the method of taking an SBOM from a big and crucial undertaking—Kubernetes—and utilizing an open supply instrument to establish the vulnerabilities it comprises. Our instance’s success reveals that we don’t want to attend for SBOM technology to achieve full maturity earlier than we start mapping SBOMs to frequent vulnerability databases. With just some updates from SBOM creators to handle present limitations in connecting the 2 sources of information, this course of is poised to grow to be simply inside attain of the common software program shopper.
OSV: Connecting SBOMs to vulnerabilities
The next instance makes use of Kubernetes, a serious undertaking that makes its SBOM out there utilizing the Software program Bundle Knowledge Change (SPDX) format—a world open customary (ISO) for speaking SBOM info. The identical thought ought to apply to any undertaking that makes its SBOM out there, and for initiatives that don’t, you may generate your individual SBOM utilizing the identical bom instrument Kubernetes created.
We’ve got chosen to map the SBOM to the Open Supply Vulnerabilities (OSV) database, which describes vulnerabilities in a format that was particularly designed to map to open supply package deal variations or commit hashes. The OSV database excels right here because it offers a standardized format and aggregates info throughout a number of ecosystems (e.g., Python, Golang, Rust) and databases (e.g., Github Advisory Database (GHSA), World Safety Database (GSD)).
To attach the SBOM to the database, we’ll use the SPDX spdx-to-osv instrument. This open supply instrument takes in an SPDX SBOM doc, queries the OSV database of vulnerabilities, and returns an enumeration of vulnerabilities current within the software program’s declared elements.
Instance: Kubernetes’ SBOM
Step one is to obtain Kubernetes’ SBOM, which is publicly out there and comprises info on the undertaking, dependencies, variations, and licenses. Anybody can obtain it with a easy curl command:
The following step is to make use of the SPDX spdx-to-osv instrument to attach the Kubernetes’ SBOM to the OSV database:
The output of the tool shows that v1.21.3 of Kubernetes contains the CVE-2020-26160 vulnerability. This information can be helpful to determine if any additional action is required to manage the risk of operating this software. For example, if an organization is using v1.21.3 of Kubernetes, measures can be taken to trigger company policy to update the deployment, which will protect the organization against attacks exploiting this vulnerability.
To get the spdx-to-osv tool to work we had to make some minor changes to disambiguate the information provided in the SBOM:
- In the current implementation of the bom tool, the version was included as part of the package name (gopkg.in/square/go-jose.v2@v2.2.2). We needed to trim the suffix to match the SPDX format, which has a different field for version number.
- The SBOM created by the bom tool does not specify an ecosystem. Without an ecosystem, it’s impossible to reliably disambiguate which library or package is affected in an automated way. Vulnerability scanners could return false positives if one ecosystem was affected but not others. It would be more helpful if the SBOM differentiated between different library and package versions.
These are relatively minor hurdles, though, and we were able to successfully run the tool with only small manual adjustments. To make the process easier in the future, we have the following recommendation for improving SBOM generation tooling:
- SBOM tooling creators should add a reference using an identification scheme such as Purl for all packages included in the software. This type of identification scheme both specifies the ecosystem and also makes package identification easier, since the scheme is more resilient to small deviations in package descriptors like the suffix example above. SPDX supports this via external references to Purl and other package identification schemas.
SBOM in the future
It’s clear that we’re getting very close to achieving the original goal of SBOMs: using them to help manage the risk of vulnerabilities in software. Our example queried the OSV database, but we will soon see the same success in mapping SBOM data to other vulnerability databases and even using them with new standards like VEX, which provides additional context around whether vulnerabilities in software have been mitigated.
Continuing on this path of widespread SBOM adoption and tooling refinement, we will hopefully soon be able to not only request and download SBOMs for every piece of software, but also use them to understand the vulnerabilities affecting any software we consume. This example is a peek into a possible future of what SBOMs can offer when we bridge the gap to connect them with vulnerability databases: a new normal of worrying less about the risks in the software we use.
A special thanks to Gary O’Neall of Source Auditor for creating the spdx-to-osv tool and contributing to this blog post.