SBOM (software bill of materials)
Updated
A software bill of materials (SBOM) is a formal, machine-readable inventory of the components and dependencies that make up a piece of software — including open-source libraries, their versions, and the relationships between them. It exists so buyers, operators, and auditors can see exactly what is inside an application without reading its source.
SBOMs matter most when a new vulnerability lands in a widely used library: instead of guessing which systems are affected, teams query their SBOMs to find every place the component ships. They are increasingly requested in procurement, security reviews, and technical due diligence, and are commonly exchanged in two standard formats, SPDX and CycloneDX.
What an SBOM is
An SBOM answers a deceptively simple question: what is actually in this software? Modern applications are assembled far more than they are written from scratch — a typical service pulls in dozens or hundreds of third-party and open-source packages, each of which pulls in its own dependencies. The SBOM is the nested ingredient list for that assembly, generated automatically from a build rather than maintained by hand.
The concept was pushed into the mainstream by US Executive Order 14028, "Improving the Nation's Cybersecurity" (2021), which directed the National Telecommunications and Information Administration (NTIA) to define the minimum elements of an SBOM. The point is transparency: a component you cannot see is a component you cannot patch, license-check, or reason about.
What an SBOM contains
The NTIA minimum elements (2021) describe the baseline data an SBOM should carry for each component, plus practices for how it is generated and shared. Two open formats dominate in practice: SPDX (standardized as ISO/IEC 5962:2021) and CycloneDX (an OWASP project). Both are machine-readable so tools can generate, merge, and query them automatically.
- Supplier and component name — who produced the part and what it is called.
- Version and unique identifiers — the exact release, plus identifiers such as a package URL or hash.
- Dependency relationships — which components depend on which, so transitive dependencies are visible.
- Author and timestamp — who assembled the SBOM data and when, so its provenance is traceable.
Why an SBOM matters
The clearest payoff is vulnerability response. When a flaw is disclosed in a common library, an organization with current SBOMs can answer "are we exposed, and where?" in minutes rather than in a manual sweep across every codebase. The same inventory supports license compliance (flagging components whose terms conflict with how the software is distributed) and supply-chain risk review.
SBOMs also surface in technical due diligence and security questionnaires, where a buyer or auditor wants an independent view of what a codebase actually depends on. An SBOM is evidence, not a guarantee: it describes composition, not whether each component is patched or safely configured, so it is a starting point for analysis rather than a verdict.
Frequently asked questions
What is the difference between SPDX and CycloneDX?
Both are open, machine-readable SBOM formats. SPDX, standardized as ISO/IEC 5962:2021, grew out of license-compliance work and is broad in scope. CycloneDX is an OWASP project designed with application security and supply-chain use cases in mind. Many tools can produce either, and the two cover the same core inventory data.
Is an SBOM the same as a vulnerability scan?
No. An SBOM is an inventory of what components are present; a vulnerability scan checks those components against known-flaw databases. They are complementary: the SBOM tells you what you have, and scanning tells you which of those items currently have reported issues. An SBOM without follow-up analysis does not tell you whether you are exposed.
How is an SBOM generated?
SBOMs are typically produced automatically during the build or from a package manifest, using tooling that walks the dependency tree and emits SPDX or CycloneDX output. Because dependencies change with every release, an SBOM is regenerated per build rather than written once, which is what keeps it accurate enough to trust during an incident.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.