Sunday, January 29, 2023
HomeCyber Securitydiscovering vulnerabilities with a Software program Invoice of Supplies

discovering vulnerabilities with a Software program Invoice of Supplies

The previous yr has seen an industry-wide effort to embrace Software program Payments of Supplies (SBOMs)—a listing of all of the parts, libraries, and modules which are required to construct a chunk of software program. Within the wake of the 2021 Government Order on Cybersecurity, these ingredient labels for software program grew to become in style as a approach to perceive what’s within the software program all of us devour. The guiding thought is that it’s unimaginable to guage the dangers of explicit software program with out realizing all of its parts—together with these produced by others. This elevated curiosity in SBOMs noticed one other enhance after the Nationwide Institute of Requirements and Expertise (NIST) launched its Safe Software program Growth Framework, which requires SBOM data to be obtainable 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 recognized vulnerabilities to know which parts might pose a risk. By connecting these two sources of knowledge, customers 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 publish, we exhibit the method of taking an SBOM from a big and essential venture—Kubernetes—and utilizing an open supply device to establish the vulnerabilities it incorporates. Our instance’s success exhibits that we don’t want to attend for SBOM era to succeed in 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 change into simply inside attain of the typical software program client.

OSV: Connecting SBOMs to vulnerabilities

The next instance makes use of Kubernetes, a significant venture that makes its SBOM obtainable utilizing the Software program Bundle Knowledge Alternate (SPDX) format—a world open customary (ISO) for speaking SBOM data. The identical thought ought to apply to any venture that makes its SBOM obtainable, and for tasks that don’t, you possibly can generate your personal SBOM utilizing the identical bom device Kubernetes created.

We now 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 package deal variations or commit hashes. The OSV database excels right here because it gives a standardized format and aggregates data 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 device. This open supply device 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 incorporates data on the venture, dependencies, variations, and licenses. Anybody can obtain it with a easy curl command:

# Obtain the Kubernetes SPDX supply doc

$ curl -L > k8s-1.21.3-source.spdx

The following step is to make use of the SPDX spdx-to-osv device to attach the Kubernetes’ SBOM to the OSV database:

# Run the spdx-to-osv device, 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 device

$ 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”: [



  “abstract”: “Authorization bypass in”,

  “particulars”: “jwt-go permits attackers to bypass meant entry restrictions in conditions with []string{} for m[“aud”] (which is allowed by the specification). As a result of the kind assertion fails, “” is the worth of aud. This can be a safety drawback if the JWT token is offered to a service that lacks its personal viewers verify. There isn’t any patch obtainable and customers of jwt-go are suggested emigrate to [golang-jwt]( at model 3.2.1″,

  “affected”: [


      “package”: {

        “name”: “”,

        “ecosystem”: “Go”,

        “purl”: “pkg:golang/”


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.

Suggestions for SBOM tooling improvements

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 ([email protected]). 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.



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments