In depth
A Software Bill of Materials (SBOM) is a structured inventory of the components that make up a software application — every direct dependency, every transitive dependency, the versions, the licences, and the cryptographic hashes that fix exactly which artefact was included. The two dominant formats are SPDX (Linux Foundation, ISO/IEC 5962:2021) and CycloneDX (OWASP project, widely used in the appsec tooling ecosystem). Both are JSON or XML, machine-parseable, and feed into vulnerability-management and licence-compliance workflows.
The SBOM became a regulatory requirement after the 2021 SolarWinds and Log4j incidents made clear that almost no organisation could answer the question "which of our deployed systems contain this vulnerable component." US Executive Order 14028 (May 2021) mandated SBOMs for federal procurement; the EU Cyber Resilience Act (enforceable 2027) extends similar obligations to most commercial software sold into the EU; FDA guidance now requires SBOMs for medical devices submitted for approval. PCI DSS v4.0 Requirement 6.3.2 also implicitly requires an SBOM-like inventory.
Practically, modern build systems generate SBOMs automatically. Syft, cdxgen, Trivy and the npm/Maven/Gradle/pip native tools can produce CycloneDX or SPDX output as a CI artefact. The SBOM is then ingested by an SCA tool (Dependabot, Renovate, Snyk, OSV-Scanner, Grype) which cross-references each component against the NVD, GitHub Security Advisory database, OSV.dev and vendor advisories to surface known CVEs. The combined pipeline produces a continuously updated dashboard of which deployments contain which vulnerable components and which remediation patches are available.
The next-generation extension is the Vulnerability Exploitability eXchange (VEX) — a complementary document that says "we ship CVE-2024-XXXXX in product X, but our usage is not affected because we do not call the vulnerable code path." Sending both SBOM and VEX to customers transforms a regulatory burden into a competitive differentiator. See Supply chain attacks 2026.
The SBOM became a regulatory requirement after the 2021 SolarWinds and Log4j incidents made clear that almost no organisation could answer the question "which of our deployed systems contain this vulnerable component." US Executive Order 14028 (May 2021) mandated SBOMs for federal procurement; the EU Cyber Resilience Act (enforceable 2027) extends similar obligations to most commercial software sold into the EU; FDA guidance now requires SBOMs for medical devices submitted for approval. PCI DSS v4.0 Requirement 6.3.2 also implicitly requires an SBOM-like inventory.
Practically, modern build systems generate SBOMs automatically. Syft, cdxgen, Trivy and the npm/Maven/Gradle/pip native tools can produce CycloneDX or SPDX output as a CI artefact. The SBOM is then ingested by an SCA tool (Dependabot, Renovate, Snyk, OSV-Scanner, Grype) which cross-references each component against the NVD, GitHub Security Advisory database, OSV.dev and vendor advisories to surface known CVEs. The combined pipeline produces a continuously updated dashboard of which deployments contain which vulnerable components and which remediation patches are available.
The next-generation extension is the Vulnerability Exploitability eXchange (VEX) — a complementary document that says "we ship CVE-2024-XXXXX in product X, but our usage is not affected because we do not call the vulnerable code path." Sending both SBOM and VEX to customers transforms a regulatory burden into a competitive differentiator. See Supply chain attacks 2026.