Every SBOM mandate since Executive Order 14028 has left one question unanswered: SPDX or CycloneDX? Both are ISO-recognized or industry-standard formats for describing what's inside a piece of software, and both show up in vendor contracts, CISA guidance, and CI/CD pipelines. But they were built by different communities for different primary use cases — SPDX grew out of license-compliance tooling at the Linux Foundation, while CycloneDX was built inside OWASP specifically for application security. That history still shapes what each format does well today. Security and compliance teams that pick the wrong one, or assume one SBOM format is a drop-in replacement for the other, end up re-generating SBOMs six months later when a customer, auditor, or the VEX workflow they need doesn't line up. This post breaks down the real differences, where each format wins, and how to stop guessing.
What is the actual difference between SPDX and CycloneDX?
SPDX and CycloneDX both encode a software bill of materials as structured data, but SPDX was designed first for license and provenance tracking while CycloneDX was designed first for vulnerability and risk management. SPDX started in 2010 under the Linux Foundation and became ISO/IEC 5962:2021, with its data model built around package relationships, copyright, and license expressions (using SPDX License List identifiers). CycloneDX launched in 2017 out of the OWASP Dependency-Track project, and its schema is built around components, services, and vulnerabilities, with native support for Vulnerability Exploitability eXchange (VEX) statements added in 2021. Both now support JSON, XML, and (SPDX only) tag-value and RDF serializations. In practice: SPDX 3.0 (released April 2024) added AI/dataset and build profiles to close the gap with CycloneDX's broader scope, and CycloneDX 1.6 (released April 2024) added formal support for cryptographic bill of materials (CBOM) and ML-BOM to compete on SPDX's traditional turf. The formats are converging in capability, but their default data models still reflect their origins.
Which SBOM format does the US government actually require?
Neither format is mandated exclusively — CISA and NTIA accept both SPDX and CycloneDX as long as the SBOM meets the "minimum elements" defined in the NTIA's July 2021 guidance. Executive Order 14028 (May 2021) directed NIST and NTIA to define SBOM minimum elements, not a specific format, and the resulting NTIA document lists three acceptable formats: SPDX, CycloneDX, and SWID tags. CISA's 2023 "types of software bill of materials" guidance reaffirmed that both SPDX and CycloneDX satisfy federal minimum-element requirements when they include supplier name, component name, version, dependency relationships, and a timestamp. The practical driver of format choice is usually downstream: if you sell into federal agencies through a prime contractor that already runs SPDX-based tooling (common in defense and aerospace supply chains), you'll be asked for SPDX. If your customer runs a DevSecOps pipeline built on tools like Dependency-Track, Trivy, or Syft's CycloneDX output, you'll be asked for CycloneDX. Some enterprise RFPs now ask for both.
Does SPDX or CycloneDX handle vulnerability data better?
CycloneDX handles vulnerability data more natively because it was the first format to build VEX (Vulnerability Exploitability eXchange) directly into its schema, starting with CycloneDX 1.4 in 2021. A CycloneDX document can carry a vulnerabilities array with CVE IDs, CVSS scores, affected version ranges, and — critically — an analysis.state field (values like exploitable, not_affected, false_positive) that lets a vendor tell a customer "this CVE is in your SBOM but isn't actually reachable in your build." SPDX didn't have an equivalent construct until SPDX 3.0's security profile shipped in 2024, and even then it defers more heavily to companion VEX documents (OpenVEX or CSAF) rather than embedding the analysis inline. For teams whose SBOM's primary job is feeding a vulnerability management pipeline — matching components against the NVD, GitHub Advisory Database, or OSV — CycloneDX's vulnerability and analysis objects mean less custom parsing. For teams whose primary job is legal license clearance before a release, SPDX's license-expression syntax (based on SPDX License List v3.25 as of 2024) is more mature and has a decade more case-law-adjacent tooling behind it.
Which format has broader tool support in 2026?
CycloneDX has the edge in security-tool-native generation, while SPDX has the edge in package-manager-native and OS-distribution generation. Anchore's Syft (one of the most widely used open-source SBOM generators) outputs both formats but defaults to CycloneDX for container scans; Trivy, Grype, and Dependency-Track are CycloneDX-first. On the SPDX side, the Linux kernel project, Yocto, and several major Linux distributions (Debian, Fedora build infrastructure via reproducible-builds tooling) publish SPDX SBOMs natively, and SPDX is the format required by some ISO 5230 (OpenChain) conformance programs. GitHub's native dependency-graph SBOM export (available since 2022) uses SPDX format by default. If your software touches both worlds — say, a container image built from a Linux base with application dependencies scanned for CVEs — you'll likely generate one format at the OS layer and another at the application layer unless your tooling converts between them.
Can you convert an SBOM between SPDX and CycloneDX without losing data?
You can convert between the two, but conversion is lossy in both directions because neither format is a strict superset of the other. Tools like the CycloneDX CLI (cyclonedx-cli convert) and Anchore's syft convert support round-tripping, but a CycloneDX document's VEX analysis states, service definitions, and pedigree/patch data have no direct SPDX 2.x equivalent, so they get dropped or flattened into generic annotations. Conversely, SPDX's granular license-expression trees (compound AND/OR/WITH operators) and file-level checksum relationships often collapse into simpler CycloneDX license fields. SPDX 3.0 narrowed this gap by adopting a more modular, profile-based structure closer to CycloneDX's component model, but as of 2026 the two ecosystems still haven't converged on a lossless bidirectional mapping. If a contract or regulation requires a specific format, generate an SBOM natively in that format at build time rather than converting after the fact — conversion should be a fallback, not a pipeline step you depend on for compliance evidence.
Should you pick one format or support both?
Most organizations end up needing to produce both formats, because different consumers of your SBOM — auditors, customers, and internal security tooling — standardize on different ones. A defense contractor customer may require SPDX for OpenChain conformance while your own AppSec team runs a CycloneDX-based vulnerability pipeline against the same build artifacts. Rather than picking a side, the more durable approach is generating SBOMs at build time in a format-agnostic intermediate representation and exporting to whichever format a given consumer needs — which is what most mature SBOM tooling, including Safeguard's, does under the hood.
How Safeguard Helps
Safeguard generates and ingests SBOMs in both SPDX and CycloneDX so you're not locked into a single downstream contract or compliance regime, and can hand a customer either format without re-scanning your build. Beyond the SBOM itself, Safeguard's reachability analysis determines whether a CVE flagged in your component inventory is actually invoked by your code at runtime — the same problem CycloneDX's VEX fields were designed to communicate, but computed automatically instead of requiring a human analyst to fill in analysis.state by hand. Griffin AI, Safeguard's triage engine, correlates that reachability data with exploit maturity and package popularity to rank findings so your team isn't drowning in every CVE that merely appears in an SBOM. When a fix is available, Safeguard opens an auto-fix pull request with the minimal version bump needed to remediate — closing the loop from "this is in our SBOM" to "this is patched" without a manual ticket in between.