SPDX vs CycloneDX
Side-by-side comparison, how to choose, conversion caveats, and NTIA minimum-element mapping.
SPDX vs CycloneDX
Neither standard is "the winner". They optimise for different things — SPDX for breadth and a formal, licence-native model; CycloneDX for operational security and implementation velocity. Most mature programmes produce both.
Side-by-side
| Dimension | SPDX | CycloneDX |
|---|---|---|
| Origin & governance | Linux Foundation SPDX workgroup, merged with the OMG/CISQ Tool-to-Tool effort. Roots in open-source licence compliance (~2010). | OWASP community project (~2017), now standardised through Ecma International TC54 with the OWASP Foundation. |
| Current stable | 3.0.1 (2024-12-17). 3.1-RC1 in review since 2026-01-24. | 1.7.2 (2026-09-17), major version 1.7 from 2025-10-21. |
| Standard status | ISO/IEC 5962:2021 (covers 2.2.1); newer edition progressing through ISO; also published via OMG. | ECMA-424 — 1st edition = 1.6 (June 2024), 2nd edition = 1.7 (11 Dec 2025). ISO fast-track next. |
| Underlying model | OWL ontology / labelled graph. Everything is an Element with an IRI; relationships are first-class elements. | Document schema. Nested JSON object with bom-ref pointers and an explicit dependencies graph. |
| Serialisation | JSON-LD (canonical), RDF/Turtle, SPDX JSON, XML, YAML; 2.x also tag:value. | JSON, XML, Protobuf. |
| Scope | Explicitly multi-domain: software, security, licensing, build, AI, datasets — plus hardware, service, safety, supply chain and operations in 3.1. | "Full-stack BOM": software, hardware, services, AI/ML, cryptography, operations, plus attestations. |
| Licensing depth | Deep. The SPDX License List is the industry vocabulary; ExpandedLicensing models licence objects, exceptions, additions, and set operators. | Deliberately lighter: components carry SPDX licence IDs or expressions. Reuses SPDX's vocabulary rather than redefining it. |
| Security depth | Security profile with vulnerability, CVSS v2/v3/v4, EPSS, SSVC, exploit-catalog and VEX assessments as separate relationship objects. | Very strong and widely implemented: vulnerabilities + analysis state, VEX documents, CBOM crypto inventory, signed CDXA attestations. |
| Component identity | IRI-based spdxId plus ExternalIdentifier (purl, CPE, SWID). | purl, cpe, swid directly on components; bom-ref for internal linking. |
| Provenance / attribution | CreationInfo on every element — creator, tool, timestamp — is mandatory in the model. | metadata at document level; 1.7's citations adds per-claim provenance for individual fields. |
| Learning curve | Higher. You need to reason about IRIs, graphs, and profiles; multiple serialisations add ambiguity. | Lower. One JSON document you can open and read; well-documented schema per version. |
| Tooling ecosystem | Good and growing; 2.x is very well supported, 3.x support still maturing. | Broadest: official libraries for Java, .NET, Go, Python, JS, Rust, PHP; plugins for Maven, Gradle, npm, Python, and most scanners. |
| Version compatibility | Hard break between 2.x and 3.x. | Backward compatible 1.4 → 1.7; deprecations only. |
How to choose
Ask what the consumer actually does with the file. The answer is usually obvious once you name the primary consumer:
| If the main consumer is… | Choose | Why |
|---|---|---|
| A vulnerability management platform | CycloneDX | VEX analysis state, service topology, and CBOM are native; ingestion is well tested. |
| A legal / OSPO licence review process | SPDX | SPDX IDs are the canonical vocabulary, and ExpandedLicensing models the edge cases. |
| An EU CRA conformity package | Either — but pin the edition | Both satisfy the technical description requirement; state SPDX 3.0.1 or CycloneDX 1.7 / ECMA-424 2nd ed. explicitly. |
| US federal procurement | Either, NTIA-complete | The requirement is about the seven minimum elements, not the format. See the mapping. |
| A post-quantum migration inventory | CycloneDX (CBOM) | 1.7's algorithmFamily and curve enum are purpose-built for crypto inventories. |
| An AI/ML governance register | Either | SPDX has the AI and Dataset profiles; CycloneDX has model cards. Pick the one your review tooling reads. |
| A customer who specified a format | That format | Generate both. It is cheaper than arguing. |
Default recommendation: make CycloneDX 1.6–1.7 your operational SBOM (broadest tooling, best security integration) and emit SPDX in parallel when a licence or procurement requirement calls for it. Keep one internal representation and generate both from the same scan.
Converting between formats
Conversion works, but it is not lossless in either direction. Know where the gaps are before you promise a customer a converted document:
- What survives: component name, version, purl/CPE identifiers, hashes, licence IDs and expressions, supplier, and the dependency graph. This covers the NTIA minimum elements, so a converted BOM is usually compliant even if it is not equivalent.
- What degrades SPDX → CycloneDX: the rich ExpandedLicensing object graph collapses to expressions;
multi-domain elements (datasets, build, AI) may have no CycloneDX equivalent; IRI-based cross-document
links become internal
bom-refs or are dropped. - What degrades CycloneDX → SPDX: service topology, compositions, formulations, CBOM crypto detail, and
CDXA attestations have no direct 3.0.1 home; per-field citations (1.7) must be flattened into
element-level
creationInfo. - Version drift: converters commonly target SPDX 2.3 rather than 3.x, so "SPDX output" may silently be a 2.x document. Check the header before you file it.
Common routes: the CycloneDX CLI can convert and downgrade output versions
(convert --output-version 1.6); Trivy and Syft can emit either format directly; and general-purpose
conversion libraries exist for programmatic pipelines. See Tooling.
Rule of thumb: convert for distribution, never as your source of truth. Keep the richest artefact your pipeline can produce, and generate the other on demand.
NTIA minimum element mapping
The seven NTIA minimum elements (US, July 2021) are the de facto compliance floor. Both standards cover all seven:
| NTIA element | SPDX | CycloneDX |
|---|---|---|
| Supplier name | Package.suppliedBy → Organization / Person | component.publisher, component.supplier, or component.manufacturer |
| Component name | Package.name | component.name |
| Version of the component | Package.packageVersion | component.version |
| Other unique identifiers | ExternalIdentifier — purl, cpe23, SWID | component.purl, component.cpe, component.swid |
| Dependency relationship | Relationship with type DEPENDS_ON | top-level dependencies array |
| Author of SBOM data | CreationInfo.createdBy (and createdUsing for tools) | metadata.authors, metadata.supplier, metadata.tools |
| Timestamp | CreationInfo.created | metadata.timestamp |
Also worth carrying, because auditors ask:
- A serial number — CycloneDX
serialNumber/ SPDX document IRI. - A completeness assertion — CycloneDX
compositions/ SPDXElement.completeness. - A data licence — SPDX
dataLicense, conventionallyCC0-1.0.
Compiled September 2026. Format mappings reflect SPDX 3.0.1 and CycloneDX 1.7; verify against current schemas before relying on them in a contract.