What is an SBOM (software bill of materials), and what makes a good one?
An SBOM inventories a software's components, versions, licenses, and suppliers for full transparency.
CycloneDX and SPDX are the NTIA formats; build-time generation is far more accurate than post-build scans.
Chainguard Containers include a high-quality SBOM generated at build time for every image.
Modern software applications contain hundreds to thousands of open source and third-party components, creating significant security challenges that SBOMs help address - which is why Chainguard includes comprehensive SBOMs with every container image. Without structured visibility into these components, organizations struggle to identify and respond to vulnerabilities, even when patches are available. This lack of transparency leaves systems vulnerable to exploitation, making SBOMs essential for maintaining secure software supply chains.
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.
And it has become recognized as one of the key building blocks of software supply chain security. Proponents rightfully point out that organizations can't secure their software if they don't know what's inside their software.
SBOM use cases
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:
Supply chain security: One of the most common uses of SBOMs is enabling users to check for security vulnerabilities in their codebase's dependencies or base images. If you learn of a vulnerability in one of the libraries your codebase depends on, you can inspect your SBOM to investigate whether your projects are affected. This security utility is further strengthened when used with VEX, the Vulnerability Exploitability eXchange, which enables you to efficiently filter out security alerts that pose no threat to your codebase.
Identify software suppliers: SBOMs can be used to identify the suppliers of software components, such as a software author or the individual or entity repackaging the software for redistribution. Supplier identity is often investigated for legal or procurement reasons and there is an evolving debate about which types of distributors should be formally considered as "suppliers".
Licensing: Software projects often pull from tens or hundreds of dependencies whose different licenses may have different restrictions on the use of the code. Being able to track the licenses of your dependencies allows you to stay informed about legal restrictions and licensing compatibility issues, and help you decide which dependencies work best for your project needs.
Automate alerts: The machine readable format of SBOMs enables you to create automated alerts to inform you of important events in your codebase, such as security vulnerabilities, missing components, or incompatible dependency licensing.
Make open source funding decisions: By understanding which open source software components are used and how frequently across an organization's codebases, an organization can make more informed decisions about providing funding to open source projects.
Find abandoned dependencies: Assuming that an SBOM's components contain sufficient information (such as
package URLs) to link packages with external data, an SBOM consumer could discover if any of the components are open source projects that are abandoned or archived. The user could then take actions such as forking the abandoned project or removing that project as a dependency.
The evolution and growing importance of SBOMs
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. The Cybersecurity and Infrastructure Security Agency (CISA), part of the Department of Homeland Security, now leads much of this work and published an updated Framing Software Component Transparency report in 2024.
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.
What makes a good SBOM?
As awareness and adoption of SBOM has grown, there has been a gradual acknowledgement that not all SBOMs are created equal, some are more or less useful, depending on the goals of the SBOM user and the contents of the SBOM. This guide exists to provide some guidance on evaluating the quality of an SBOM, suggesting common use cases and the data fields that support these use cases and open source SBOM quality tools.
Basic SBOM use cases and required SBOM data
Identifying Vulnerable Components: To enable this use case, SBOMs must contain information, at a minimum, about the component name and version. Because there are many different open source software package ecosystems, it is also advantageous to include information about the package ecosystem from which a component originates. This reduces the chances of a false positive when identifying potential vulnerabilities. A package URL (or purl) provides this ecosystem information. Additionally, SBOMs ought to include all transitive dependencies, dependencies of dependencies.
Identifying Licenses: To enable license analysis, an SBOM must contain information about the license or licenses associated with all components. Additionally, there is a supplier data field that can help organizations understand component suppliers.
Ensuring Software Integrity: SBOMs can also help organizations and individuals ensure software integrity, discovering instances of tampering where a party has introduced malicious functionality.
Providing checksums for packages or files within the SBOM enables machine-verification of software integrity.
Note: There are other SBOM use cases, such as mapping broader ecosystem risks, but this guide currently focuses on the arguably three relatively well-established SBOM use cases.
Open source SBOM tools
SBOM creation tools
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.
SBOM formats
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.
Your choice of format also affects which downstream tools can read the SBOM. Vulnerability scanners and software composition analysis (SCA) tools vary in how completely they parse each format, so confirm that the tools in your pipeline support the format you generate or consume.
Quality measurement tools
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 NTIA's minimum requirements. The following tools are helpful for assessing the quality of SBOMs you use or create:
The open source SBOM Scorecard, created by eBay, analyzes SPDX and CycloneDX formats according to evolving key fields such as spec compliance, licensing information, and package data.
The open source NTIA Conformance Checker analyzes whether an SPDX SBOM meets the NTIA's minimum elements, such as supplier's name, dependency relationship, and timestamp.
Stewardship of this guidance has since moved from the NTIA to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), which published an updated Framing Software Component Transparency report in 2024 and released a draft update to the minimum elements in 2025. The core data fields remain consistent, so an SBOM that satisfies the NTIA minimum elements is a sound baseline today.
Signing SBOMs
Signing your SBOM is an important way of assuring 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 guide to SBOMs vs. attestations.
Learn more
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:
Related articles