When a critical vulnerability like Log4Shell drops at 11pm on a Friday, the first question every security team asks is: "which of our products use Log4j?" Without an SBOM, answering that question means grep-ing through build files, chasing dependency declarations in ten different repos, and hoping nobody missed an indirect import. With an SBOM, it is a single query.
A Software Bill of Materials (SBOM) is a machine-readable inventory of every component — library, package, framework, dependency — that went into a piece of software.
A complete SBOM includes, for each component: the exact name and version shipped (not a range), the supplier, a PURL (Package URL) such as pkg:npm/[email protected] that tools can resolve without ambiguity, the SPDX license identifier, SHA-256 hashes for integrity verification, and the dependency graph. Modern SBOMs in the CycloneDX 1.6 format also embed VEX (Vulnerability Exploitability eXchange) data — statements about which CVEs affect your specific build.
CycloneDX is an OWASP standard designed for security use cases: JSON or XML, compact, and well-supported by tools that want to do something actionable with the SBOM — like scanning it for vulnerabilities or generating VEX documents. SPDX is a Linux Foundation standard originally designed for license compliance and now widely used in government procurement; U.S. federal agencies increasingly require SPDX SBOMs under the May 2021 executive order on cybersecurity. Both formats are useful and most modern tooling can ingest either.
U.S. federal agencies and their suppliers face increasing SBOM mandates. The EU Cyber Resilience Act will require them for CE-marked products. Beyond compliance, an SBOM is useful for incident response (query rather than audit every codebase), M&A due diligence (assess security and license risk before the deal closes), license compliance (know every copyleft dependency before you ship), and change tracking (diff two SBOMs across releases to audit what changed).
DepWarden generates a CycloneDX 1.6 SBOM with embedded VEX from any manifest or lockfile scan and accepts existing CycloneDX and SPDX SBOMs as input. An SBOM is most valuable when generated automatically in CI/CD and kept up to date — a stale one gives false confidence. Related: what Log4Shell taught us about supply-chain security.