The previous 12 months has seen an industry-wide effort to embrace Software program Payments of Supplies (SBOMs)—an inventory of all of the parts, libraries, and modules which can be required to construct a chunk of software program. Within the wake of the 2021 Govt Order on Cybersecurity, these ingredient labels for software program grew to become widespread as a option to perceive what’s within the software program all of us eat. The guiding thought is that it’s inconceivable to evaluate the dangers of specific software program with out understanding all of its parts—together with these produced by others. This elevated curiosity in SBOMs noticed one other increase after the Nationwide Institute of Requirements and Expertise (NIST) launched its Safe Software program Growth Framework, which requires SBOM info to be obtainable for software program. However now that the {industry} is making progress on strategies to generate and share SBOMs, what will 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 an inventory of recognized vulnerabilities to know which parts may pose a risk. By connecting these two sources of data, shoppers will know not simply what’s of their software program, but additionally its dangers and whether or not they should remediate any points.
On this weblog submit, we show the method of taking an SBOM from a big and essential undertaking—Kubernetes—and utilizing an open supply software to establish the vulnerabilities it comprises. Our instance’s success exhibits that we don’t want to attend for SBOM technology to achieve full maturity earlier than we start mapping SBOMs to widespread 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 turn out to be simply inside attain of the common software program client.
OSV: Connecting SBOMs to vulnerabilities
The next instance makes use of Kubernetes, a serious undertaking that makes its SBOM obtainable utilizing the Software program Bundle Knowledge Alternate (SPDX) format—a global open normal (ISO) for speaking SBOM info. The identical thought ought to apply to any undertaking that makes its SBOM obtainable, and for initiatives that don’t, you may generate your individual SBOM utilizing the identical bom software Kubernetes created.
Now we have 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 bundle variations or commit hashes. The OSV database excels right here because it supplies a standardized format and aggregates info throughout a number of ecosystems (e.g., Python, Golang, Rust) and databases (e.g., Github Advisory Database (GHSA), International Safety Database (GSD)).
To attach the SBOM to the database, we’ll use the SPDX spdx-to-osv software. This open supply software 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 parts.
Instance: Kubernetes’ SBOM
Step one is to obtain Kubernetes’ SBOM, which is publicly obtainable 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 software 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.
