The previous yr 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 are required to construct a bit of software program. Within the wake of the 2021 Government Order on Cybersecurity, these ingredient labels for software program grew to become standard as a solution to perceive what’s within the software program all of us devour. The guiding thought is that it’s not possible to guage the dangers of specific software program with out realizing all of its elements—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 data to be out there 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 out there for a given piece of software program, it must be mapped onto a listing of identified vulnerabilities to know which elements might pose a menace. By connecting these two sources of knowledge, customers will know not simply what’s in what’s of their software program, but additionally its dangers and whether or not they should remediate any points.
On this weblog put up, we exhibit the method of taking an SBOM from a big and crucial mission—Kubernetes—and utilizing an open supply instrument to determine 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 frequent vulnerability databases. With just some updates from SBOM creators to deal with 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 mission that makes its SBOM out there utilizing the Software program Bundle Information Trade (SPDX) format—a global open normal (ISO) for speaking SBOM data. The identical thought ought to apply to any mission that makes its SBOM out there, and for initiatives that don’t, you may generate your personal SBOM utilizing the identical bom instrument Kubernetes created.
We’ve 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 supplies a standardized format and aggregates data 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 data on the mission, dependencies, variations, and licenses. Anybody can obtain it with a easy curl command:
“`
# Obtain the Kubernetes SPDX supply doc
curl -L https://sbom.k8s.io/v1.21.3/supply > k8s-1.21.3-source.spdx
“`
The subsequent step is to make use of the SPDX spdx-to-osv instrument to attach the Kubernetes’ SBOM to the OSV database:
“`
# Run the spdx-to-osv instrument, taking the data from the SPDX SBOM and mapping it to OSV vulnerabilities
$ java -jar ./goal/spdx-to-osv-0.0.4-SNAPSHOT-jar-with-dependencies.jar -I k8s-1.21.3-source.spdx -O out-k8s.1.21.3.json
…
# Present the output OSV vulnerabilities of the spdx-to-osv instrument
$ cat out-k8s.1.21.3.json
…
{
“id”: “GHSA-w73w-5m7g-f7qc”,
“printed”: “2021-05-18T21:08:21Z”,
“modified”: “2021-06-28T21:32:34Z”,
“aliases”: [
“CVE-2020-26160”
],
“abstract”: “Authorization bypass in github.com/dgrijalva/jwt-go”,
“particulars”: “jwt-go permits attackers to bypass supposed entry restrictions in conditions with []string{} for m[“aud”] (which is allowed by the specification). As a result of the sort assertion fails, “” is the worth of aud. It is a safety downside if the JWT token is offered to a service that lacks its personal viewers test. There is no such thing as a patch out there and customers of jwt-go are suggested emigrate to [golang-jwt](https://github.com/golang-jwt/jwt) at model 3.2.1″,
“affected”: [
{
“package”: {
“name”: “github.com/dgrijalva/jwt-go”,
“ecosystem”: “Go”,
“purl”: “pkg:golang/github.com/dgrijalva/jwt-go”
},
…
“`
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.
