Every SBOM programme has the same first argument. Half the room wants CycloneDX, half the room wants SPDX, and somebody invariably suggests "let's just support both", which is the worst answer. The two formats started in different communities solving different problems, and although they have converged on a lot of ground in 2025-2026, the differences that remain are exactly the differences that matter when you are picking a single canonical format for an enterprise programme. CycloneDX 1.6 came from OWASP with an emphasis on application security, vulnerability tracking, and now AI components. SPDX 3.0 came from the Linux Foundation with an emphasis on licence compliance, legal review, and software composition transparency. Both are ISO standards in some form. Both have credible tooling. Both can describe a typical Java or Node application competently. The honest answer to "which should we use?" depends on the centre of gravity of your programme, the formats your suppliers actually emit, and whether AI-BOM and VEX live in your near-term roadmap. This post lays out the practical comparison and gives a defensible default.
The Origin Story Still Matters
CycloneDX was created in 2017 inside OWASP to make SBOM useful for application security. Its data model treats the BOM as the spine of a security-decision pipeline: components, services, vulnerabilities, VEX statements, and now ML model components are all first-class. The schema is JSON-first, the tooling lives heavily in the build-pipeline ecosystem, and the format updates roughly twice a year.
SPDX was created in 2010 by the Linux Foundation primarily to enable licence compliance at enterprise scale. The original SPDX 2.x focused on package-level metadata, file-level licence concluded vs declared distinctions, and a robust short-identifier system for licences. SPDX 3.0, finalised in 2024, modernised the model into profiles (Core, Software, Build, AI, Dataset, Security) and is now JSON-LD-based with first-class AI and dataset support.
Both formats are now serious. The choice is no longer about who has more features; it is about which set of features matches your programme's centre of gravity.
Field Coverage In 2026
CycloneDX 1.6 captures: components with purl, services, vulnerabilities, VEX inline, signatures, ML model components (mlModel), data components, formulation (build process), and external references. The schema is dense, vulnerability-aware, and pipeline-friendly. Average emitted-file size for a typical Node service: 600-900 KB.
SPDX 3.0 captures: software packages, files, snippets, relationships, licences (declared and concluded), AI profile metadata, dataset profile metadata, build profile metadata, and security profile metadata. The relationship model is more expressive than CycloneDX, especially for "this file is derived from that file" assertions that legal review depends on. Average emitted-file size for the same Node service: 1.2-1.8 MB because the file-level granularity is richer.
Practical effect: if your programme spends a lot of time on questions like "which files in this binary derive from a GPL-3.0 source", SPDX wins on expressiveness. If your programme spends a lot of time on questions like "which products contain this component at this version, and what is our VEX position", CycloneDX wins on density.
Tooling Maturity
This is where the difference is widest in practice.
CycloneDX has a deep build-pipeline tooling story. cyclonedx-cli, cdxgen, ecosystem-specific emitters for Maven, Gradle, npm, pip, Go, Rust, and Cargo, and broad CI integration. Most modern container scanners emit CycloneDX natively. Most VEX tooling is CycloneDX-first.
SPDX has the deepest licence-tooling story. FOSSology, ScanCode Toolkit, the SPDX licence list, and broad legal-tool integration all centre on SPDX. SPDX 3.0 tooling is improving rapidly through 2025-2026, but as of Q1 2026 the build-pipeline emitters lag CycloneDX equivalents in two practical respects: purl coverage is lower in some emitters, and AI profile emitters are still sparse.
If you are going to build the programme on the back of CI emitters, CycloneDX has fewer rough edges in 2026. If you are going to build it on the back of legal review tooling, SPDX has fewer rough edges.
AI-BOM And ML Component Support
Both formats now support AI components, but they took different routes.
CycloneDX 1.6 added mlModel and data component types directly to the core schema. The same SBOM document can describe Python wheels and a Llama-3.1-8B fine-tune. This is convenient for programmes that want a single artefact per release covering the full software-and-model surface.
SPDX 3.0 added the AI and Dataset profiles as separate but related modules. The relationship model lets you express "this software package depends on this AI model, which derives from this dataset" with explicit graph edges. This is more expressive but produces a larger document and a steeper authoring curve.
For a programme starting AI-BOM in 2026, CycloneDX 1.6 is the lower-friction default. For a programme that already runs SPDX 3.0 deeply for licence reasons, the AI profile is the correct extension.
VEX
CycloneDX has inline VEX support and is the natural pairing with CSAF 2.0 for cross-vendor VEX exchange. The combination CycloneDX + CSAF VEX is the de facto industry default for "here is our SBOM and here is our position on the vulnerabilities affecting it" as of 2026.
SPDX VEX support exists through the security profile in 3.0 but is less mature in tooling and less common in vendor-emitted artefacts. If VEX is a major part of your noise-reduction plan, this matters.
A Defensible Default
Most programmes should standardise on CycloneDX 1.6 as the canonical internal format, with a normalisation layer that converts inbound SPDX to CycloneDX at ingest. The reasons: better build-pipeline tooling, denser per-file footprint, native AI-BOM in the same document, and the strongest VEX ecosystem.
Programmes whose centre of gravity is licence compliance, particularly in regulated open-source-heavy environments, should standardise on SPDX 3.0 internally and convert inbound CycloneDX. The licence relationship model is materially more useful for legal review than CycloneDX's, and the SPDX licence list is unmatched.
Avoid running both as canonical. Pick one, normalise the other at ingest, and keep the conversion deterministic. The pain of dual-canonical formats is silent and compounding: every dashboard, query, and policy gate ends up with two implementations that drift.
How Safeguard Helps
Safeguard ingests CycloneDX 1.4, 1.5, and 1.6, plus SPDX 2.3 and 3.0, and normalises every inbound artefact into a single canonical model keyed by purl. The platform preserves source-format provenance so legal teams can pull the original SPDX licence relationships, while security teams query the normalised view for vulnerability and VEX context. AI-BOM extensions support both CycloneDX 1.6 mlModel/data components and SPDX 3.0 AI/Dataset profiles. VEX ingest accepts CSAF 2.0 and CycloneDX VEX with full cross-format mapping. Signed attestations cover both formats through a Sigstore-compatible chain. The result is a programme that picks a canonical format without losing the inbound diversity that real supplier ecosystems will always have.