Software Bill of Materials (SBOM)
An SBOM is a machine-readable inventory of every component in a build, with versions, identifiers, and relationships, so teams can answer what is inside shipped software.
Definition
A software bill of materials is a structured artifact listing the components, libraries, and packages included in a software product, with names, versions, suppliers, cryptographic hashes, and dependency relationships, usually expressed in SPDX or CycloneDX.
Context and scope
Use it when shipping software to customers, responding to a new vulnerability, or meeting procurement and regulatory requirements that demand component transparency.
Common misconceptions
- The lockfile is an SBOM; it covers one ecosystem and omits OS packages and container layers
- Generating an SBOM once at release is enough; it must be regenerated for every artifact
- An SBOM tells you whether you are exploitable; it only tells you what is present
Anti-patterns
- Producing a PDF or spreadsheet that no tool can parse
- Listing direct dependencies only and omitting transitive components
- Publishing an SBOM without package URLs or hashes, making matching unreliable
Related concepts
Related examples
Authoritative source
What an SBOM contains
An SBOM is an inventory, not a vulnerability report. It lists each component with a name, version, supplier, and a package URL (pURL) or CPE identifier, plus hashes and the relationships between components. For containers it should include OS packages and base image layers, not just the application’s language dependencies.
How it works
Generation belongs in the build pipeline, where the resolved dependency graph is known. Tools read manifests and lockfiles, inspect container layers, and emit SPDX or CycloneDX JSON. The artifact is signed and stored next to the release, ideally referenced from the image or release metadata.
Consumers use the SBOM for incident response: when a new CVE lands, they query which shipped versions include the affected component and where. Combined with VEX statements, which record whether a product is actually affected, this separates presence from exploitability.
When to use it
Produce an SBOM for every externally shipped artifact and every container image. It is also useful internally during upgrades, license audits, and merger due diligence. Regulated sectors and public procurement increasingly require one per release.
Trade-offs
Complete SBOMs are large and noisy, especially for containers with hundreds of OS packages. Accuracy depends on the generator; lockfile-only tools miss system libraries. Formats differ in detail, so tooling must normalize pURLs. Maintaining a pipeline that regenerates and signs SBOMs adds build time and storage.
Example and misconceptions
After a widely used logging library vulnerability, a team queries its SBOMs and finds three services shipping the affected version, including one where it arrived transitively through an SDK. Without the SBOM, that service would have been missed.
The common misconception is that an SBOM is a security assessment. It is an ingredient list; risk depends on whether the ingredient is reachable and exploitable in context.
Related concepts: Supply Chain Security, SLSA, and Vulnerability Disclosure.