Software bill of materials (SBOM)

The modern SBOM effort began with the US NTIA multistakeholder process in 2018 and was given regulatory weight by Executive Order 14028 (May 2021), after which NTIA published The Minimum Elements for an SBOM (July 2021). It defines three groups: data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and timestamp), automation support (a machine-readable format - SPDX, CycloneDX or SWID tags), and practices and processes (frequency of regeneration, depth, handling of known unknowns, distribution and access control).

Two formats dominate. SPDX, from the Linux Foundation, was standardised as ISO/IEC 5962:2021 (SPDX 2.2.1); SPDX 3.0 (2024) restructured the model into profiles for security, licensing, AI and datasets. CycloneDX, from OWASP, is standardised by Ecma as ECMA-424 (first edition June 2024, second edition December 2025) and also covers services, hardware, machine-learning models (ML-BOM), cryptographic assets (CBOM) and embedded vulnerability or VEX data. Components are identified by Package URLs (purl, e.g. pkg:npm/lodash@4.17.21) and sometimes CPE names; accurate identifiers are what make automated vulnerability matching possible, and inconsistent CPEs are a common cause of both false positives and misses.

SBOMs differ by when they are produced; CISA's taxonomy distinguishes design, source, build, analysed, deployed and runtime SBOMs. A build SBOM generated by the package manager or build tool during compilation is usually the most complete; an analysed SBOM produced by scanning a finished binary or container image (Syft, Trivy, cdxgen) can miss statically linked, vendored or shaded code. Depth matters: many dependencies are transitive, and an SBOM listing only direct dependencies would have hidden most Log4j exposure in 2021. SBOMs are commonly attached to releases or container images as signed in-toto attestations so recipients can verify their origin.

An SBOM is an inventory, not an assessment. Its value appears when it is ingested into tooling (for example OWASP Dependency-Track) and continuously correlated with vulnerability data, and when paired with VEX (Vulnerability Exploitability eXchange, in CSAF or OpenVEX form), in which the supplier states whether a listed vulnerability actually affects the product. In the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I Part II point 1, requires manufacturers to identify and document components, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies; the SBOM belongs to the technical documentation and need not be published. The CRA's main obligations apply from 11 December 2027, while its vulnerability-reporting duties have applied since 11 September 2026. SBOM differs from software composition analysis, which is the process that consumes or produces such inventories to find vulnerable and non-compliant components.