SBOM
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, and dependency — along with their versions and relationships — that make up a piece of software, analogous to an ingredients list for…
Definition
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, and dependency — along with their versions and relationships — that make up a piece of software, analogous to an ingredients list for a manufactured product.
Overview
An SBOM's purpose is to answer a deceptively hard question quickly: 'exactly what open-source and third-party code is inside this application, and which version?' Without an SBOM, organizations often can't answer this reliably, especially for transitive dependencies buried several layers deep. When a critical vulnerability like Log4Shell (the 2021 Log4j vulnerability) is disclosed, organizations with SBOMs can immediately query which of their systems include the affected component, while organizations without them must scramble to audit codebases manually — a process that took many teams weeks in the Log4j incident. SBOMs are typically generated automatically as part of the build process using tools like Syft, CycloneDX generators, or Trivy, and are expressed in one of two dominant standard formats: SPDX (Software Package Data Exchange, an ISO standard originally from the Linux Foundation) or CycloneDX (from the OWASP Foundation), both of which are machine-readable (typically JSON or XML) so they can be automatically ingested by vulnerability scanners and compliance tooling. An SBOM lists each component's name, version, supplier, license, and cryptographic hash, and can express dependency relationships (what depends on what) to support deep transitive analysis. SBOMs gained major regulatory and industry momentum after the US Executive Order 14028 (2021) directed NTIA guidance requiring SBOMs for software sold to the federal government, and they're now commonly requested in vendor security questionnaires and required by some industry frameworks. Beyond compliance, SBOMs support license compliance auditing (catching incompatible open-source licenses before they create legal risk), and feed directly into continuous vulnerability monitoring, since a component's presence can be automatically cross-referenced against newly disclosed CVEs the moment they're published. SBOMs are a foundational building block of broader software supply chain security practices, working alongside artifact signing and build provenance attestation (e.g. SLSA) to establish trust in a software artifact's origin and contents.
Key Concepts
- Machine-readable inventory of every component, library, and version in a software artifact
- Expressed in standard formats: SPDX (ISO standard) or CycloneDX (OWASP)
- Generated automatically during builds via tools like Syft, Trivy, or CycloneDX generators
- Captures component name, version, supplier, license, and cryptographic hash
- Enables rapid vulnerability impact assessment when a new CVE is disclosed
- Mandated for federal software vendors under US Executive Order 14028 / NTIA guidance
- Supports open-source license compliance auditing
- Foundational input to broader supply chain security and SLSA provenance attestation