What is an SBOM (Software Bill of Materials)?

An SBOM is a nested, signable document — usually JSON, XML, or tag-value text — that lists every “component” a piece of software contains, the relationships between those components (what depends on what), and metadata such as supplier, version, license, cryptographic hash, and known vulnerability identifiers. NTIA’s 2021 Minimum Elements for a Software Bill of Materials defines seven required data fields (supplier, component name, version, unique identifier, dependency relationship, author, timestamp) and three required practices (automation support, practices and processes, known unknowns). It is the foundation document that downstream tools — SCA scanners, VEX advisories, license-compliance checkers, reproducible-build attestors — operate on.

The push for SBOMs accelerated after a chain of supply-chain incidents that exposed how little anyone knew about what was actually inside the software they shipped. The 2020 SolarWinds Orion compromise (CVE-2020-10148) inserted the SUNBURST backdoor into roughly 18,000 downstream environments via a signed update. The December 2021 Log4Shell disclosure (CVE-2021-44228, CVSS 10.0) revealed that a single deserialization flaw in Apache Log4j 2 sat under a meaningful fraction of the entire Java ecosystem. The 2024 XZ Utils backdoor (CVE-2024-3094, CVSS 10.0) showed the same problem at the OS layer: a maintainer-level social-engineering attack against liblzma came within weeks of landing in stable Debian and Fedora.

U.S. federal policy followed. Executive Order 14028 (May 12, 2021) directed NIST to publish secure-software-development guidance and required SBOMs for federal software purchases. NIST SP 800-218 (SSDF v1.1, February 2022) operationalized that requirement. CISA published the Types of SBOM Documentstaxonomy in April 2023, defining six SBOM types — Design, Source, Build, Analyzed, Deployed, and Runtime. The EU’s Cyber Resilience Act (Regulation (EU) 2024/2847, in force December 2024) imposes a parallel obligation across European markets, with full applicability from December 2027.

Two formats dominate. SPDX (Software Package Data Exchange) is maintained by the Linux Foundation and was ratified as ISO/IEC 5962:2021. CycloneDX is maintained by OWASP and ships richer support for VEX (Vulnerability Exploitability eXchange) statements, which let a vendor publish “yes, we ship Log4j, but the vulnerable code path is not reachable in our product” — a critical signal that prevents downstream SBOM consumers from drowning in false-positive alerts. CISA’s 2023 VEX guidance and the OASIS CSAF 2.0 specification both standardize how VEX is expressed.

In practice, SBOMs are generated automatically at build time by tools like Syft (Anchore), Trivy (Aqua Security), cdxgen (CycloneDX), and Microsoft’s sbom-tool. They are then signed (often via Sigstore/cosign), stored as OCI artifacts alongside container images, and consumed by SCA platforms (Snyk, Dependency-Track, GitHub Dependabot) that continuously diff the SBOM against vulnerability feeds like NVD, GHSA, and OSV.dev.