Can SBOMs Save the Software Supply Chain?

A major problem in today’s software landscape is knowing what software you’re using, where it came from, and who built it. The software supply chain is, in many ways, similar to most physical supply chains.

Take, for example, a salad. There are several steps before a dinner salad makes it to your plate: It must be grown, picked, cleaned, shipped, stocked, purchased, and then prepared. Software is similar: Before you can download an app, software developers must design, write, test, debug, lint, build, and ship that code. Each step of this process often depends on an essentially unknown number of other software components—often open source—written by an unknown number of other software developers. But the similarities stop here. While most people eating a salad can trace contaminated lettuce back to the source using the product’s lot number, performing the same step with software with security defects is more an aspiration than a reality. 

There is a big difference between tomorrow’s SBOM promise and today’s SBOM reality.

Enter the much-vaunted Software Bill of Materials, better known as SBOMs, an ingredients list of what is in a piece of software. This is a document (often a JavaScript Object Notation, JSON, file) that contains a manifest of packages or files inside a piece of software. For each software package, for instance, an SBOM lists information like the package’s name, version, and license. 

SBOMs, more than any other software supply chain security concept or technology, have captured the attention of software producers and consumers interested in software transparency. At their core, SBOMs promise faster vulnerability response by providing information about what’s in a piece of software. Some industry groups are now pushing to implement SBOMs everywhere. Unfortunately, there is a big difference between tomorrow’s SBOM promise and today’s SBOM reality.

State of Today’s SBOMs

In theory, technology vendors generate SBOMs and give them to software consumers or buyers who use them for vulnerability management, open-source software license compliance, and purchasing decisions, among other reasons.

The recent SBOM hype is primarily driven by potential U.S. federal government requirements for vendors and government contractors to provide SBOMs for critical software. Less talked about, though, is the quality of today’s SBOMs and the ability of organizations to consume and analyze them.

In the Cyber Safety Review Board’s first report, which dealt with the Log4Shell vulnerability associated with open source Java component Log4j, the analysis found no instances of organizations using SBOMs to find vulnerable Log4j deployments—even among organizations that already use SBOMs.

The CRSB report points out that current deficiencies in SBOM tools and practices, including bad input data like variances in field descriptions and a lack of version information about cataloged software components, may explain their lack of tangible help during Log4j remediation.

Additionally, the report mentions that “addressing SBOM standardization gaps would support a faster software supply chain vulnerability response.” With this analysis in mind from CRSB, advocates will see improved SBOM data and tooling as possible with more effort. Skeptics of SBOMs, however, will see this episode as validation of the inherent limitations of SBOMs.

Vulnerability discovery is often touted as a silver bullet use case of SBOMs, so this finding was, to understate the matter, discouraging.

The good news, though, is that some organizations were at least using SBOMs—a step in the right direction from where the industry was a few years ago when SBOMs were rarely discussed. CRSB’s report uncovered many SBOM gaps and concluded they are limited, specifically, “by variances in field descriptions and a lack of version information about cataloged components, and lack of automation on the consumption end due to these variances.”

My company recently analyzed open-source software SBOM quality and came to a similar conclusion as the CRSB’s Log4j report. Our research found that some open-source project SBOMs are low quality and lack important information—like package license details and package version history. Additionally, none of the SBOMs we reviewed conformed to the standards of the National Telecommunications and Information Administration's (NTIA) minimum elements framework.

Again, it’s not all bad news, though, since the analysis also found that some open-source projects do have high-quality SBOMs that contain helpful information, especially package IDs, package versions, and licenses. In our SBOM quality research, Flux—a Cloud Native Computing Foundation project—had the highest SBOM quality score among the SBOMs analyzed. Its SBOM is generated with Syft in the SPDX format and includes high-quality SBOM information like license verification, origin, version, and checksum.

To further complicate matters, there is emerging evidence that the quality of SBOMs depends not just on the SBOM creation tool involved but on the software component that is being analyzed. Some software artifacts include files that are untracked by package manager metadata, the data that feeds SBOM creation tools and results in accurate SBOMs. These untracked files, so-called software dark matter, complicate the jobs of many across the industry who are seeking deeper software transparency through SBOMs.

Achieving the Promise of Tomorrow’s SBOMs

There are four key ingredients SBOMs need to strengthen their quality, to help organizations meet tomorrow’s federal software requirements, and, in turn, make the software supply chain secure by default.

• First, SBOMs must strive for completeness, which means they ought to be created at a piece of software’s build time rather than after the fact. We need to create high-quality SBOMs, preferably by using build tools that automatically generate SBOMs from source rather than unreliably recovering SBOMs from finished software products through reverse engineering methods.
  
  
• Second, SBOMs need minimum standards—likely differing by intended use—to ensure that SBOMs serve the goals of the many parties in the software ecosystem.
  
  
• Third, SBOMs should use software signing schemas. To trust the SBOM for a piece of software, a digital signing mechanism should be used to verify the SBOM is what it claims to be and is coming from a trusted source. The open-source project Sigstore is one example of a digital signing method that can be used for signing SBOMs.
  
  
• Fourth, to simplify the challenge of making SBOMs useful, organizations should focus on collecting the SBOMs that really matter—for the software that is actually in production.

By using these key ingredients to generate SBOMs, we can start moving towards a stage where SBOMs are truly useful and deliver on their promises. 

Improving SBOM Quality Instead of Quantity

For readers who want the software to salad analogy to fully apply—to ensure that consumers can avoid tainted software just as easily as contaminated lettuce—it’s promising to see such excitement about SBOMs as a tool to increase software transparency. But instead of just making SBOMs everywhere, we should also strive to ensure that SBOMs are high quality using the key ingredients outlined above.

Dan Lorenc is co-founder and CEO of Chainguard, a leading software supply chain security company. Lorenc has been working on and worrying about containers since 2015 as an engineer and manager. He started projects like Minikube, Skaffold, and Kaniko to make containers easy and fun. In the process, he became worried about the state of open source software supply-chains and so partnered with Kim Lewandowski and others to found the Tekton, Sigstore, and SLSA projects to make it easier to build and use containers securely.