Every software supply chain security mandate from the last five years — Executive Order 14028, the FDA's 2023 premarket cybersecurity guidance, PCI DSS 4.0 — comes back to the same three-letter acronym: SBOM. But ask two security teams which SBOM format they use and you'll get different answers, because there are two competing standards: CycloneDX and SPDX. Both list your software's components, licenses, and dependencies. Neither is going away. CycloneDX, born inside OWASP in 2017, was built security-first and now natively carries vulnerability exploitability data. SPDX, a Linux Foundation project dating to 2010, became ISO/IEC 5962:2021 and was built license-first for compliance and provenance. In practice, most mature security programs end up generating both, because vendors, regulators, and internal tooling each lean a different way. This piece breaks down where the two formats actually diverge, what the 2021-2024 standards timeline changed, and how to decide which one to lead with.
What's actually different between CycloneDX and SPDX?
CycloneDX and SPDX both describe a "bill of materials," but they were designed to answer different questions. SPDX started in 2010 as a way to standardize license and copyright metadata so legal teams could audit open source usage without manually reading source headers — it has roughly 500 entries in its own SPDX License List and a formal relationship model (DESCRIBES, CONTAINS, DEPENDS_ON) for expressing provenance precisely. CycloneDX launched in 2017 out of the OWASP Dependency-Track project with a narrower, security-first goal: give vulnerability scanners a lightweight, machine-readable component inventory they could match against CVE feeds. That heritage still shows up in the schemas today. SPDX 3.0, released in April 2024, expanded into a full "system description" model covering AI datasets, builds, and licensing in one graph. CycloneDX 1.6, released in April 2024, added native support for cryptographic assets (post-quantum readiness) and formalized VEX and ML-BOM profiles. Same category of document, two different centers of gravity.
Which format does the U.S. government actually require?
Neither — the government requires the NTIA's "minimum elements" data fields, not a specific file format, and both CycloneDX and SPDX satisfy them. The July 2021 NTIA minimum elements document (issued under Executive Order 14028) lists required fields like supplier name, component name, version, and dependency relationships, but explicitly names both SPDX and CycloneDX as acceptable serializations. CISA has published guidance and tooling (like the SBOM-a-rama series) that treats the two as interchangeable inputs. Where you do see a lean: federal agencies publishing their own SBOMs and open source-heavy ecosystems have historically defaulted to SPDX because of its ISO standardization, while commercial AppSec vendors and vulnerability management platforms — Dependency-Track, Anchore, and most container scanners — default to CycloneDX because it's easier to pipe straight into a vulnerability database. If a contract or RFP just says "SBOM required," ask which format the counterparty's tooling actually ingests before you pick one.
How do the two formats handle vulnerability data?
CycloneDX handles it natively; SPDX handles it as an attached, separate document. CycloneDX has a first-class VEX (Vulnerability Exploitability eXchange) profile built into the same schema as the component list, so a scanner can emit "component X has CVE-2024-1234, but it's not exploitable in this context" as a structured field in one document. SPDX 3.0 added a comparable Vulnerability and VexStatement class in its 2024 rewrite, but it's a newer addition bolted onto a format whose core model was built for license graphs, and tool support for it is still catching up — most SPDX-based scanners as of 2024-2025 still ship vulnerability data as a separate CSV or JSON sidecar rather than embedded VEX. This is the single biggest reason security teams — as opposed to legal or compliance teams — tend to gravitate toward CycloneDX: it was built to answer "am I actually exposed" in one query, not two.
Which format wins on license and provenance compliance?
SPDX wins here, by design, not by accident. Its relationship model was purpose-built to answer legal questions: who supplied this component, under what license, and what does it depend on transitively. The SPDX License List (updated multiple times a year, with SPDX 3.2.1 as a recent point release) is the de facto standard that license-scanning tools like FOSSA and Black Duck already map against, which means an SPDX document plugs into legal review workflows with less translation. CycloneDX supports license fields too (SPDX license identifiers, in fact — CycloneDX reuses SPDX's license taxonomy rather than inventing its own), but its relationship model is flatter and wasn't built for the kind of nested provenance chains that in-depth license audits or export-control reviews need. If your primary driver is a legal/IP audit or you're responding to a due-diligence request in an M&A deal, SPDX is the format your counterparty's lawyers will expect.
What do real-world tools and ecosystems actually support?
Support is broad on both sides, but defaults differ by tool category. Syft (Anchore's SBOM generator) and Trivy (Aqua Security) can emit both CycloneDX and SPDX from the same scan, but ship CycloneDX as the default output format. cdxgen, one of the most widely used SBOM generators for JavaScript, Python, and Java projects, is CycloneDX-native by name and design. On the SPDX side, spdx-sbom-generator and the tern container tool are common choices, and GitHub's own dependency graph export defaults to SPDX JSON. Package registries are inconsistent too: npm's npm sbom command (added in npm 9.6+) supports both formats via a flag. The practical result: if your pipeline already includes a container or dependency scanner, check what it emits by default before mandating a format company-wide — forcing a conversion step between formats is where SBOM programs quietly break down, since not every field maps 1:1 across schemas.
Which format should you actually pick in 2026?
Pick based on your primary consumer, and expect to eventually support both. If your SBOMs feed a vulnerability management or VEX workflow — the majority use case for security teams — CycloneDX's native VEX and vulnerability schema will save you a translation layer. If your SBOMs need to satisfy legal, export-control, or M&A due-diligence review, SPDX's ISO 5962:2021 status and license-graph model will be the format your counterparty expects. If you sell into the federal government or medical device space (FDA's 2023 guidance explicitly accepts both), check the specific contract or agency guidance rather than assuming — some agencies have started requesting SPDX specifically for supply-chain provenance while requesting CycloneDX-format VEX statements for the same product. The organizations we work with that have the least SBOM friction are the ones generating both formats from a single source of truth at build time, rather than trying to convert one into the other after the fact — cross-format conversion tools exist but routinely drop or flatten fields, especially around nested relationships and custom properties.
How Safeguard Helps
Safeguard generates CycloneDX and SPDX SBOMs from the same build-time scan, so you're never stuck converting one format into the other after the fact and losing fidelity in the process. Every SBOM Safeguard produces carries native CycloneDX VEX statements for exploitability triage alongside SPDX-compliant license and provenance data for legal and compliance review — one pipeline, both outputs, no manual reconciliation. Safeguard also tracks which format each downstream consumer (a customer, a regulator, an internal team) actually requires and routes the right document automatically, so your engineering team stops fielding "can you resend that as SPDX" tickets. For teams managing NTIA minimum-elements compliance, FDA premarket submissions, or vendor due-diligence requests side by side, Safeguard keeps both SBOM formats current and audit-ready from a single source of truth, instead of two SBOM programs running in parallel.