Today, software products often contain hundreds to thousands of different open source and third-party software components, many of which are unknown to the software operator or end user. Without an organized way of overseeing these components, it is difficult — or even impossible — to identify and respond to security risks associated with these individual components. Even when software distributors identify vulnerabilities and provide patches, software operators may not have a way to identify vulnerable components quickly enough. Or, in the worst case, operators remain entirely unaware of these vulnerabilities, enabling malicious actors to exploit them without their knowledge.
A software bill of materials, or an SBOM (pronounced s-bomb), is a key resource for enabling visibility into the different software components of a codebase. Often described as a list of software “ingredients,” an SBOM is a formally structured list of libraries, modules, licensing, and version information that make up any given piece of software. An SBOM’s purpose is to enable software operators (or any type of software user) to have a comprehensive view of their codebase so that they can quickly identify software components that have known vulnerabilities, or investigate other tracked features like patch status, supplier, license, or version.
SBOMs are leveraged for a variety of purposes, which will likely continue to evolve as new use cases are identified. Some of the most prominent uses of SBOMs today are:
For more than a decade, a variety of communities have worked on standards for generating and sharing SBOMs or SBOM-relevant resources, with institutional support from organizations and government agencies like the Linux Foundation and the Department of Commerce. Discussion of SBOMs grew significantly after the White House signed a cybersecurity executive order in May 2021, which in turn led the National Institute of Standards and Technology (NIST) and Department of Commerce to recommend the requirement of SBOMs for all software used by the federal government. This recommendation was based on the logic that SBOMs, had they been in use, would have helped minimize damage of recent large scale software supply chain security incidents such as SolarWinds. More recently, the Department of Homeland Security demonstrated the U.S. government’s sustained interest in SBOMs by supporting and funding the SBOM community’s research and development.
Even without requirements, SBOMs are becoming increasingly popular in industry given their utility for managing security risks and licensing, and providing greater visibility into an organization’s codebase. SBOM tools and practices, however, are still maturing and have yet to realize their full potential as an industry practice. While there has been an uptick in the creation and use of SBOMs, many of these SBOMs fail to meet the minimum requirements set forth by the Department of Commerce. For example, in an analysis of 3,000 SBOMs taken from a list of popular Docker containers, Chainguard Labs found that only one percent of SBOMs conformed with the minimum required elements. Nonetheless, proponents of SBOMs (such as Chainguard) remain optimistic about their potential. As industry strengthens SBOM tooling and practices, SBOMs continue to hold great promise for helping secure software supply chains.
Currently, most SBOMs are generated after the build process using a variety of tools that can scan the software for packages, licensing info, and other information relevant to an SBOM. Syft and Trivy are two popular open source tools for generating SBOMs for containers after the build process, along with bom, an open source tool for creating, viewing, and transforming SBOMs for Kubernetes and other projects.
One downside of generating SBOMs after the build process is that scanners typically do not recognize components that are not registered with a package management system. Thus, locally built software components can be missed by the scanner and result in the generation of an SBOM that is missing critical information about the software’s inventory.
Ideally, SBOMs should be generated during the build process, which enables a higher level of accuracy given that the SBOM can be generated directly from the software inventory rather than from database records. Though build systems do not typically provide support for this approach, more build tools are beginning to integrate features for generating SBOMs, such as apko, a tool for building and publishing OCI container images.
When selecting an SBOM generation tool, it’s important to make sure it supports the format you wish to use. Though there are a variety of available SBOM formats, most SBOMs follow either CycloneDX or SPDX, both of which are approved by the National Telecommunications and Information Administration for fulfilling the executive order’s SBOM requirement.
An SBOM’s utility is dependent on the quality and comprehensiveness of the information it contains. As noted above, many SBOMs available today fail to meet the NITA’s minimum requirements. The following tools are helpful for assessing the quality of SBOMs you use or create:
Signing your SBOM is an important way of ensuring end users that it has not been tampered with by a third party and that it comes from a trusted source (you). You can learn more about how to use Cosign, an open source tool for signing containers and other software artifacts, to sign your SBOM in our tutorial.
In this guide, you have learned about the purpose of SBOMs and why proponents see them as a critical building block for software supply chain security. You have also learned about key tools and formats used in SBOM production and consumption, and how to measure the quality of the SBOMs you generate or consume.
SBOM practices and tooling are actively evolving. To learn more about SBOMs, check out related research by Chainguard Labs, such as: