# Software Bill of Materials (SBOM) Deep-Dive
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component that makes up a piece of software. Modeled after the bill of materials used in manufacturing, an SBOM enumerates the open source libraries, third-party packages, and commercial components embedded in an application, along with metadata describing each component's identity, provenance, and licensing. The term gained regulatory weight in 2021 when Executive Order 14028 mandated SBOMs for software sold to the federal government, but the operational value of SBOMs extends well beyond compliance: they are the foundation for continuous vulnerability tracking, license governance, and supply chain risk management.
Where a traditional vulnerability scanner might periodically sweep a running application, an SBOM provides a persistent, queryable record of what software is actually present, independent of when it is running. When a new CVE is published, an organization with a maintained SBOM can answer in seconds whether any of its applications contain the affected component. Without one, the same question can take days of manual triage across every codebase.
SBOMs exist in two primary formats, each with distinct ecosystems of tooling and standards body backing: SPDX (Software Package Data Exchange) and CycloneDX. Understanding both formats, and the tools that generate them, is prerequisite knowledge for any team operating a mature software supply chain security program.
---
SPDX is the older and more broadly standardized of the two formats. Developed under the Linux Foundation and ratified as ISO/IEC 5962:2021, SPDX defines a document schema that supports multiple serialization formats: tag-value (a human-readable key-value text format), JSON, YAML, RDF/XML, and spreadsheet. SPDX documents are organized around packages, files, and snippets, and they capture detailed licensing information (individual file-level license expressions are possible). Because of its ISO status, SPDX carries the most regulatory and procurement weight, particularly with U.S. federal agencies that explicitly reference it in SBOM guidance from CISA and NTIA.
CycloneDX is an OWASP project. It serializes to JSON and XML and is oriented more explicitly toward security use cases than toward license compliance. CycloneDX introduced the concept of VEX (Vulnerability Exploitability eXchange) documents as a companion format, and its schema includes first-class support for services, hardware, and machine learning model metadata, in addition to traditional software components. For teams primarily concerned with vulnerability management rather than license auditing, CycloneDX is often easier to work with.
Both formats represent the same underlying data model. Conversion utilities exist to move between them, and modern tooling increasingly supports generating either format from a single invocation.
The National Telecommunications and Information Administration (NTIA) published minimum element guidance for SBOMs in 2021, identifying the floor of what a useful SBOM must contain:
pkg:npm/lodash@4.17.21, pkg:pypi/requests@2.28.2). PURLs are package-ecosystem-specific and unambiguous.Beyond the minimums, a production-grade SBOM also includes checksums (SHA-256 hashes of component archives for integrity verification), declared licenses (SPDX license expression syntax), copyright notices, and download locations. The richer the metadata, the more useful the SBOM becomes for both vulnerability correlation and license compliance enforcement.
SBOMs must be generated, not manually authored. The tooling ecosystem is mature:
Syft (Anchore) is an open source CLI tool and Go library that generates SBOMs from container images, filesystems, archives, and supported package ecosystems (npm, pip, Maven, Go modules, and more). Syft integrates natively with Grype, Anchore's open source vulnerability scanner, allowing a pipeline to generate an SBOM and scan it in a single workflow. Output formats include SPDX JSON, CycloneDX JSON/XML, and Syft's own JSON format.
Trivy (Aqua Security) is primarily a vulnerability scanner but includes SBOM generation as a first-class feature. Because it combines scanning and SBOM generation in a single tool, Trivy is a common choice for teams that want minimal toolchain complexity. It supports container images, filesystems, Git repositories, and Kubernetes clusters.
cdxgen is a multi-language CycloneDX generator. It has unusually broad language support, including JavaScript, Python, Java, Rust, Go, C#, Ruby, and Dart. For polyglot monorepos, cdxgen is often the most practical option since it can traverse the entire repository and produce a single merged CycloneDX document covering all language ecosystems.
Microsoft SBOM Tool is an open source tool from Microsoft focused on SPDX generation. It was designed for integration into Azure DevOps and GitHub Actions pipelines and handles repositories with mixed language ecosystems well.
Anchore Enterprise is a commercial platform built on top of the open source Anchore engine, adding SBOM storage, policy enforcement, drift detection, and integrations with vulnerability databases beyond NVD.
---
The Log4Shell crisis of December 2021 illustrated the SBOM gap in stark terms. When CVE-2021-44228 was published, most organizations had no reliable answer to "which of our applications uses Log4j?" Developers manually searched codebases, searched container images, asked other developers. The process was slow, error-prone, and missed transitive dependencies where Log4j was pulled in not directly by the application but by a library the application depended on.
An organization with a maintained SBOM and a working correlation pipeline could query: "which SBOMs in our registry contain a component matching pkg:maven/org.apache.logging.log4j/log4j-core?" The answer would arrive in seconds, filtered to specific versions, with affected systems identified before the first patch was even available.
This is the core value proposition: SBOMs convert the reactive "what is vulnerable?" question into a continuous, automated monitoring problem.
Beyond security, SBOMs serve legal and compliance functions. Open source licenses impose obligations. GPL-licensed components require derivative works to be released under compatible terms. LGPL components have different distribution requirements. AGPL adds network-use provisions. An organization that ships a product without knowing its license composition is exposed to legal risk from organizations like the Software Freedom Conservancy that actively enforce GPL violations.
Executive Order 14028 (Improving the Nation's Cybersecurity, May 2021) directed the federal government to require SBOMs from software vendors as a condition of procurement. CISA has published substantial guidance on SBOM implementation, including format recommendations and minimum element requirements. The FDA has issued guidance requiring SBOMs for medical device software. The European Union's Cyber Resilience Act (CRA), which entered into force in 2024, imposes SBOM requirements on hardware and software products sold in the EU market.
Federal contractors and regulated industry vendors who cannot produce SBOMs on demand are increasingly unable to close enterprise and government deals.
---
The canonical SBOM workflow integrates generation into the build pipeline rather than treating it as a manual or post-hoc process. A production pipeline looks like this:
referrers API). The SBOM is stored alongside and linked to the image digest.A raw vulnerability scan against an SBOM will generate false positives. A component may contain a vulnerable code path that the application never calls. A CVE may be present in the component but mitigated by a configuration the application uses. VEX documents allow a vendor to assert the exploitability status of a CVE against a specific product version.
VEX defines four statuses:
CycloneDX supports VEX as a document type within the same schema. CISA has also published a standalone VEX format. When consuming third-party software, requesting VEX documents alongside SBOMs allows automated tools to filter scanner output to only actionable findings.
When receiving software from a vendor, the consuming organization should:
---
CDA's Continuous Surface Reduction (CSR) methodology treats SBOM generation and continuous scanning as core controls within the VSD domain. CSR's core principle is directional: "Every surface you expose is a surface we eliminate." Every untracked dependency is an unmonitored surface. SBOMs make that surface visible; continuous vulnerability correlation keeps it measured.
Within the CSR operational workflow, SBOM generation is a required step in any pipeline that produces a deployable artifact. CDA recommends CycloneDX as the primary format for security-focused workflows given its first-class VEX support, with SPDX for any deliverables going to federal customers where ISO/IEC 5962:2021 alignment is required.
CDA also applies SBOM logic to its own service estate. Every deployed Cloudflare Worker and Next.js application in the CDA ecosystem has a corresponding SBOM maintained in the artifact registry. When new CVEs are published against Node.js packages or Rust crates used in the Worker runtime, the monitoring pipeline generates alerts before a threat actor could exploit the window between disclosure and remediation.
For clients onboarded through CDA's managed security programs, SBOM program setup is part of the initial engagement scope under the VSD domain. This includes toolchain selection, pipeline integration, artifact registry configuration, and continuous monitoring subscription.
---
---