CycloneDX and SPDX are the two formats that satisfy the CRA's machine-readable SBOM requirement. Choosing between them is not a compliance question: both qualify. It is a workflow question about which format fits how your team handles vulnerability tracking and license compliance. CycloneDX is an OWASP project optimised for security use cases. SPDX is a Linux Foundation standard that carries ISO/IEC 5962:2021 recognition. This page compares both on the dimensions that matter for CRA and BSI TR-03183 compliance, with working examples of each.
Summary
- Both CycloneDX (OWASP) and SPDX (Linux Foundation) satisfy the CRA's machine-readable format requirement
- CycloneDX 1.6 or later is preferred for security workflows; native VEX support arrived in 1.4 and the rich
evidencestructure in 1.5 - SPDX 2.2.1 is the version standardised as ISO/IEC 5962:2021; SPDX 2.3 is the current stable revision and is backwards-compatible with the ISO baseline. SPDX 3.0 is in progress as ISO/IEC DIS 5962
- Format choice does not affect which fields you owe under BSI TR-03183: the field requirements are the same for both
Which SBOM formats are accepted under the CRA?
The CRA requires "commonly used and machine-readable" formats. In practice, two standards qualify:
| Format | Standard | Best For |
|---|---|---|
| CycloneDX | OWASP | Security-focused, native VEX support |
| SPDX | Linux Foundation | License compliance, broader adoption |
Both formats are accepted. CycloneDX is increasingly preferred for security use cases due to its native support for:
- Vulnerability Exploitability eXchange (VEX)
- Security advisories
- Dependency graphs
graph LR
SCN[Component Names] --- SBOM((SBOM))
VS[Versions] --- SBOM
SUP[Supplier Info] --- SBOM
DEP[Dependencies] --- SBOM
SBOM --- LIC[Licenses]
SBOM --- PURL[Package URLs]
SBOM --- HASH[Hash Values]
SBOM --- OSC[Open Source Components]
style SBOM fill:#008080,color:#fff,stroke:#006666,stroke-width:4px
style SCN fill:#e8f4f8,stroke:#008080,color:#333
style VS fill:#e8f4f8,stroke:#008080,color:#333
style SUP fill:#e8f4f8,stroke:#008080,color:#333
style DEP fill:#e8f4f8,stroke:#008080,color:#333
style LIC fill:#e8f4f8,stroke:#008080,color:#333
style PURL fill:#e8f4f8,stroke:#008080,color:#333
style HASH fill:#e8f4f8,stroke:#008080,color:#333
style OSC fill:#e8f4f8,stroke:#008080,color:#333
Side by side
| Dimension | CycloneDX | SPDX |
|---|---|---|
| Origin | OWASP project | Linux Foundation |
| Latest stable spec | 1.7 (Oct 2025); target 1.6 or later for CRA | 2.3 (current); 3.0 in ISO DIS |
| Standards recognition | OWASP, ECMA TC54 (in progress) | ISO/IEC 5962:2021 (covers SPDX 2.2.1) |
| Primary focus | Security and vulnerability management | Licence compliance and legal review |
| VEX support | Native (since 1.4, Jan 2022) | Via external CSAF |
Component evidence |
Identity and occurrences since 1.5 (Jun 2023) | Not applicable |
| Licence expression | Adequate | Comprehensive (SPDX licence list is canonical) |
| Tooling | Syft, Trivy, cdxgen produce CycloneDX natively | Syft, scancode-toolkit, FOSSA |
| Spec weight | Lighter, easier to implement | More comprehensive, more verbose |
CycloneDX
OWASP project. Designed for security from the ground up: lighter spec, native VEX, direct CVE linking, strong native tooling (Trivy, Syft, cdxgen). Pick CycloneDX when vulnerability tracking is the priority.
Example CycloneDX component entry:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"components": [
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/lodash@4.17.21",
"hashes": [
{
"alg": "SHA-256",
"content": "cc6d..."
}
],
"licenses": [
{
"license": {
"id": "MIT"
}
}
]
}
]
}
SPDX
Linux Foundation standard. SPDX 2.2.1 is recognised as ISO/IEC 5962:2021; SPDX 2.3 is the current stable revision and stays backwards-compatible with the ISO baseline. Comprehensive licence expression syntax, longer track record in supply-chain compliance, and stronger handling of complex licensing scenarios. Pick SPDX when licence compliance and legal review drive your workflow.
Example SPDX component entry:
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "my-application",
"packages": [
{
"SPDXID": "SPDXRef-Package-lodash",
"name": "lodash",
"versionInfo": "4.17.21",
"downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
"licenseConcluded": "MIT",
"checksums": [
{
"algorithm": "SHA256",
"checksumValue": "cc6d..."
}
]
}
]
}
How to choose
| Use Case | Recommendation |
|---|---|
| Primary focus is security and vulnerabilities | CycloneDX |
| Primary focus is licence compliance | SPDX |
| Need VEX integration for vulnerability workflows | CycloneDX |
| Enterprise with existing SPDX tooling | SPDX |
| German market (BSI TR-03183 alignment) | Either (both recommended) |
| Starting fresh with no prior format preference | CycloneDX (simpler, security-focused) |
For CRA compliance, either format works. The CRA does not name a preferred format. Pick one and be consistent across your product portfolio. You can generate both from the same build using tools like Syft or Trivy, but standardising on one reduces operational overhead.
The format you choose does not affect which fields you must populate. Name, version, supplier, PURL, hash, license, and dependency relationships are required under BSI TR-03183 regardless of whether your SBOM is CycloneDX or SPDX.
Frequently Asked Questions
What SBOM formats does the CRA accept?
The CRA requires formats that are "commonly used and machine-readable." CycloneDX (OWASP) and SPDX (Linux Foundation) are the two formats that satisfy this requirement. The regulation does not name them explicitly, but no other formats currently meet the bar in practice.
CycloneDX or SPDX: which should I pick for CRA compliance?
Both satisfy the CRA's "commonly used and machine-readable" requirement. Pick CycloneDX if your priority is security: it has native VEX (Vulnerability Exploitability eXchange) support, a tighter fit for vulnerability workflows, and is increasingly the format of choice for CRA-aligned tooling. Pick SPDX if your priority is license compliance, broader ISO recognition (ISO/IEC 5962), or you already have SPDX in place from prior open-source compliance work. You can produce both from the same build, but standardizing on one across your product portfolio reduces operational overhead. The format choice does not affect what fields you owe under BSI TR-03183.