CycloneDX or SPDX? Choosing an SBOM format
On this page
Two open standards share almost all software bills of materials: CycloneDX and SPDX. Both are recognised internationally, both are read by every serious tool, and both are accepted for the Cyber Resilience Act, which only asks for “a commonly used and machine-readable format”. The choice is less important than producing a complete SBOM for every release. Still, they come from different places, and the differences matter for some uses.
If you are new to SBOMs, start with What is an SBOM?.
At a glance
| CycloneDX | SPDX | |
|---|---|---|
| Steward | OWASP and Ecma International (TC54) | Linux Foundation |
| Started | 2017, for application security | 2010, for open-source licence compliance |
| Formal standard | ECMA-424 (1st edition: version 1.6, 2nd edition: version 1.7) | ISO/IEC 5962:2021 (version 2.2.1) |
| Current version | 1.7 (October 2025) | 3.0.1 (December 2024) |
| Serialisations | JSON, XML, Protocol Buffers | 3.x: JSON-LD; 2.x: JSON, YAML, XML, tag-value, RDF/XML, spreadsheet |
| Beyond software | Services (SaaS), hardware, firmware, ML models, cryptography, manufacturing | Profiles for security, AI, datasets, builds, licensing |
| Vulnerabilities and VEX | Built in | Security profile (3.x); usually a separate VEX document |
| Licences | SPDX licence identifiers and expressions | Native, the reference for licence data |
CycloneDX: built for security
CycloneDX was designed by the OWASP community to answer one question quickly: which known vulnerabilities affect what I ship? Its model is a list of components with their identifiers (package URL, CPE, hashes), a dependency graph, and optional sections for vulnerabilities, their analysis and the services a product calls.
That makes it convenient when the SBOM feeds a vulnerability process. A CycloneDX document can carry VEX information directly: for each vulnerability, whether the product is affected and why. It also covers more than libraries: hardware bills of materials, SaaS services, machine-learning models and the cryptographic assets a product uses.
SPDX: built for licences, now broader
SPDX (Software Package Data Exchange) began as a way to exchange licence information about open-source packages, and it remains the reference there: the SPDX licence identifiers (MIT, Apache-2.0, GPL-3.0-only) are used everywhere, CycloneDX included. Its 2.x versions describe packages, files and snippets with their licences, copyrights and relationships.
SPDX 3.0, published in 2024, rebuilt the model around elements and relationships, with profiles: security (vulnerabilities and VEX relationships), AI and datasets, build, and a “lite” profile for the minimum. Tooling for 3.x is still catching up with 2.3, which many generators produce by default.
What the CRA and the authorities accept
The CRA names no format. Germany’s BSI, whose technical guideline TR-03183-2 (version 2.1, August 2025) is the most detailed reading so far, accepts CycloneDX 1.6 or later and SPDX 3.0.1 or later, in JSON or XML. The US minimum elements (NTIA, now CISA) also name both. Whatever you choose, what an authority will look at is the content: every component with a version, a supplier and a unique identifier, the dependencies, and an SBOM for each release.
Which one to choose
- You mainly want vulnerability management and the CRA: CycloneDX. VEX fits in the same file, the tooling for security is the most mature, and 1.6 meets the BSI baseline today.
- Your legal team already works with SPDX for licences, or a customer requires it: SPDX, ideally 3.0.1 as soon as your tools support it (2.3, still the most common, does not meet the BSI guideline).
- You sell to many customers: produce one, export the other. Converting is possible, with some loss of detail, because the two models do not match field for field.
What matters more than the format:
- Generate the SBOM in the build, for every release, never by hand.
- Give every component a package URL, so it can be matched against vulnerability databases.
- List transitive dependencies, not only direct ones.
- Validate the file against the official schema before you publish or archive it.
You can open a CycloneDX or SPDX file in our free SBOM viewer and checker to see its components and what is missing.
Tools that produce and convert
Most generators write both: Syft, Trivy and cdxgen produce CycloneDX and SPDX (cdxgen writes SPDX 3.0.1); Microsoft’s sbom-tool focuses on SPDX; the CycloneDX build plugins for Maven, Gradle, npm, .NET and Python write CycloneDX. GitHub can export the dependency graph of a repository as SPDX. For conversion and validation, the CycloneDX CLI and the SPDX tools are the references, and the OpenSSF project protobom converts between the two through a neutral model.
How Provetry helps
Provetry writes the SBOM of every release in CycloneDX 1.6 on every plan, and in SPDX 2.3 and SPDX 3.0.1 on paid plans, from your CI or from the lock files you upload, and keeps each one with its release.