SPDX 3.0.1 vs CycloneDX 1.7: Choose an SBOM Format by Exchange Job, Not a Winner Score
Published August 2026 by Solarc Labs
Both standards have expanded well beyond a flat software package list
SPDX 3.0.1 describes a System Package Data Exchange model whose scope includes software composition, build information, AI models, datasets, provenance and integrity, licensing, vulnerabilities and relationships between system elements. CycloneDX 1.7 describes a modular BOM model that covers software, hardware, services, cryptographic assets and AI models, together with dependency, vulnerability, licensing and other supply-chain information. That makes a simplistic “SPDX is for licences, CycloneDX is for security” split increasingly misleading. Both ecosystems can carry richer data than those old shorthand descriptions imply.
The current versions have different model and serialization choices
SPDX 3.0.1 uses a profile-based data model and documents RDF-derived serializations including JSON-LD. CycloneDX 1.7 publishes JSON, XML and Protocol Buffers representations and identifies 1.7 as the current production specification on its specification overview. Those differences matter when a buyer or tool expects a specific file shape. “Supports SPDX” or “supports CycloneDX” is not precise enough for an integration contract; version, profile, serialization and the fields your workflow actually depends on should be named explicitly.
Interoperability should be tested with the exact downstream job
A procurement team performing licence disposition may care about component identity, licence expressions and relationships. A vulnerability workflow may care about component identifiers and vulnerability data. A cryptography program may care about algorithm and asset inventory. A build-integrity workflow may care about provenance. The right format is therefore the one the producer can generate accurately and the downstream consumer can parse without silently dropping the fields that matter. If two partners use different standards, translation needs its own loss and validation test rather than an assumption that every field maps one-to-one.
Version pinning is part of evidence quality
SPDX explicitly states that exchanged information needs transparent specification-version identification, and CycloneDX carries a specVersion field. A review pipeline should preserve that version with the input evidence instead of normalizing every incoming BOM into a generic “SBOM” label. This becomes especially important as standards evolve. A parser that was validated against an earlier major version should not silently treat a newer model as equivalent just because the filename still ends in JSON.
For licence review, accept supported inputs and keep the legal boundary narrow
Solarc’s SBOM licence-review job starts from a customer-provided supported CycloneDX or SPDX JSON SBOM, normalizes the components it can understand, applies deterministic licence-policy states and routes unknown or ambiguous cases to human disposition. It does not need to declare one SBOM standard universally superior. The buyer-safe question is whether the exact input version is supported and whether the evidence needed for the licence decision survives the parse. Licence-policy review is also not legal clearance, vulnerability scanning or a certification of the SBOM producer.
Primary sources
Sources used for this article
Continue the job