CycloneDX vs SPDX: Picking Your CRA-Compliant SBOM Format

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 evidence structure 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
2
Qualifying formats
CycloneDX or SPDX
VEX
CycloneDX native
Vulnerability eXploitability
ISO 5962
SPDX 2.2.1 recognition
2021 international standard
Dec 2027
Full enforcement
Format must be in place

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.

BSI TR-03183 field requirements apply to both formats

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.

What to do next

  1. Confirm your format: CycloneDX for security-first teams, SPDX if you have existing license compliance workflows. If unsure, start with CycloneDX (1.4 minimum for CRA).
  2. Check your required fields against BSI TR-03183 quality levels: name, version, supplier, PURL/CPE, hash, dependencies, licenses. These apply to both formats.
  3. Understand the Annex I obligations your SBOM must satisfy: see CRA SBOM requirements for format, scope, and Annex VII documentation rules.
  4. Automate generation in CI/CD with Syft, Trivy, or cdxgen. A manual export does not satisfy the ongoing update obligation triggered by each release, patch, or component change.
  5. Place your SBOM in the Annex VII technical file (point 2(b) for the vulnerability-handling description; point 8 for on-request copies), ready for market surveillance authorities. If you would rather not wire SBOM intake from scratch, CRA Evidence handles CycloneDX/SPDX intake and TR-03183 quality scoring across product versions.