Security teams generating their first software bill of materials almost always hit the same fork in the road: CycloneDX or SPDX? Both are machine-readable formats for listing the components, versions, and dependencies inside an application, and both satisfy the SBOM requirement in Executive Order 14028. But they were built for different jobs. SPDX started in 2010 as a Linux Foundation project focused on open-source license compliance. CycloneDX started in 2017 out of the OWASP Dependency-Track project with application security as the primary use case. That origin story still shows up in how each format handles vulnerability data, license metadata, and extensibility today. This post breaks down the practical differences — schema depth, tooling support, regulatory recognition, and conversion tradeoffs — so you can pick the right format instead of defaulting to whatever your scanner happens to output first.
What's the core difference between CycloneDX and SPDX?
CycloneDX is optimized for security use cases like vulnerability tracking and exploitability exchange, while SPDX is optimized for legal and license compliance with broader coverage of non-software artifacts. CycloneDX 1.6, released in April 2024, has first-class support for VEX (Vulnerability Exploitability eXchange) statements, cryptographic bill of materials (CBOM) data, and machine learning bill of materials (ML-BOM) fields baked directly into the core schema. SPDX 3.0, released in March 2024, restructured the format around a generalized "profile" model — Core, Software, Licensing, Security, Build, AI, Dataset — that lets it describe provenance for things well outside a codebase, including AI training data and build pipelines. In practice, a security team scanning containers for a specific CVE will find CycloneDX's vulnerability object model faster to work with; a legal team auditing license obligations across an M&A target's codebase will find SPDX's license expression syntax (based on the SPDX License List of 500+ identifiers) more precise.
Which SBOM format do U.S. regulations actually require?
Neither — U.S. federal guidance is format-agnostic and explicitly accepts both CycloneDX and SPDX. The NTIA's "Minimum Elements for a Software Bill of Materials" report, published July 12, 2021, defines required data fields (supplier name, component name, version, dependency relationships, unique identifiers) but does not mandate a specific format. CISA's 2023 SBOM types guidance and the SBOM tooling reference both list CycloneDX and SPDX as acceptable. The FDA's premarket cybersecurity requirements for medical devices, which became enforceable in October 2023 under Section 524B of the FD&C Act, likewise accept either format as long as the minimum elements are present. Where you do see a de facto lean toward one format is in industry practice: SPDX has stronger roots in enterprise license-compliance workflows because of its Linux Foundation heritage, while CycloneDX has become the default output format for security-focused scanners like OWASP Dependency-Track, Trivy, and Grype. Also worth noting: SPDX became an ISO/IEC international standard (ISO/IEC 5962:2021) in 2021, and CycloneDX was approved as Ecma International standard ECMA-424 in December 2024 — so both now carry formal standards-body backing, which matters for vendors selling into regulated industries that require ISO-recognized formats.
Does CycloneDX or SPDX handle vulnerability data better?
CycloneDX handles vulnerability data more natively because it includes a dedicated vulnerabilities object in its core schema, whereas SPDX only added comparable capability with the Security profile in SPDX 3.0. A CycloneDX document can carry CVE IDs, CVSS scores, affected version ranges, and VEX status (affected, not_affected, fixed, under_investigation) directly alongside the component inventory in one file. SPDX's Security profile, introduced with the 3.0 spec revision, can express similar data but requires linking separate SPDX elements together via relationships rather than embedding them in a single vulnerability object — a structurally different approach that most tooling built before 2024 doesn't yet fully support. This is why most vulnerability-management platforms — including scanners feeding into CI/CD pipelines — ingest and emit CycloneDX by default, and why the OpenVEX and CSAF (Common Security Advisory Framework) exchange formats were designed to interoperate most directly with CycloneDX's vulnerability model. If your primary use case is continuous vulnerability triage rather than license auditing, CycloneDX will generally require less custom tooling to get vulnerability context out of the SBOM itself.
Can you convert between CycloneDX and SPDX without losing data?
You can convert between them, but lossless conversion isn't guaranteed because the two schemas don't map one-to-one, especially for security and licensing metadata. Tools like the CycloneDX CLI's cyclonedx-cli convert command and Anchore's Syft (which can output SPDX 2.3, SPDX 3.0, and CycloneDX 1.6 from a single scan) handle the common fields — component names, versions, PURLs, basic dependency graphs — reliably. Where conversion gets lossy is in format-specific extensions: CycloneDX VEX statements and CBOM cryptographic metadata have no direct SPDX equivalent prior to the 3.0 Security profile, and SPDX's fine-grained license expression syntax (e.g., combinations using WITH exceptions or custom LicenseRef- identifiers) can degrade to a generic string when converted to CycloneDX's simpler license object. The practical takeaway: pick your primary format based on your dominant use case (security vs. compliance) and treat conversion as a one-way bridge for interoperability with a specific downstream consumer, not as a way to maintain two systems of record without loss.
Which format should security teams choose for supply chain risk management?
Security and DevSecOps teams should default to CycloneDX for vulnerability management and reserve SPDX for scenarios involving license audits, government contract deliverables, or non-software artifact tracking. This isn't a universal rule — some organizations standardize on SPDX because a specific customer contract or regulatory submission requires it — but for the common case of continuously monitoring open-source dependencies for exploitable CVEs across dozens or hundreds of repositories, CycloneDX's native vulnerability and VEX support reduces the amount of custom integration work needed to get from "here's an SBOM" to "here's what's actually exploitable in production." Many container and CI/CD-native scanners (Trivy, Grype, Docker Scout) default to CycloneDX output for exactly this reason. Teams operating in regulated industries — healthcare, automotive (ISO/SAE 21434), or federal contracting — should check contract language before committing, since some agencies and primes still specify SPDX by name in vendor requirements.
How Safeguard Helps
Safeguard ingests both CycloneDX and SPDX SBOMs — including SPDX 2.3, SPDX 3.0, and CycloneDX 1.4 through 1.6 — and normalizes them into a unified component graph so security teams don't have to pick a format and live with the gaps. For teams that don't yet have an SBOM pipeline, Safeguard generates CycloneDX SBOMs directly from source repositories and container images, with VEX status attached automatically. The real differentiator is what happens after ingestion: Safeguard's reachability analysis determines whether a vulnerable function in a flagged component is actually called by your application code, cutting through the noise of CVEs that show up in an SBOM but pose no real exploitability risk. Griffin AI, Safeguard's reasoning engine, correlates that reachability data with exploit intelligence to prioritize the vulnerabilities that matter, and for the ones that do, Safeguard opens auto-fix pull requests with the minimum version bump needed to remediate — turning an SBOM from a compliance artifact into an actionable remediation queue.