CRA SBOM Format Guide 2026: CycloneDX vs SPDX for EU Cyber Resilience Act Compliance

Post #2 in the sota.io EU CRA SBOM Developer Guide Series (2026)

The Cyber Resilience Act (EU 2024/2847) mandates a Software Bill of Materials but deliberately does not specify which format you must use. This flexibility is intentional — the regulation leaves format selection to market standards — but it creates a real decision for engineering and compliance teams: CycloneDX or SPDX?

This is post #2 in our five-part CRA SBOM developer series. Post #1 covered the regulatory foundation: what Art.13, Art.31, and Annex VII actually require. Here we translate those requirements into format selection criteria and give you a clear recommendation.

What CRA Annex VII Requires From Your SBOM Format

Before comparing formats, let's ground the decision in what the regulation actually demands. Annex VII Category 4 requires that your SBOM:

1. Identifies all software components — including open-source libraries, third-party packages, and internal modules
2. Specifies version information — exact version strings for each component (not ranges, not "latest")
3. Enables vulnerability assessment — the list must be sufficient for identifying and evaluating known vulnerabilities against public databases such as the CVE registry
4. Remains updatable — Annex VII documentation must be kept current throughout the supported lifecycle per Art.31

Two additional practical requirements flow from other CRA obligations:

• Machine-readable format — market surveillance authorities may request documentation in formats they can process programmatically; a PDF table does not satisfy this
• Vulnerability linkage — Art.14 requires manufacturers to actively monitor for newly discovered vulnerabilities in their components and to address them; this loop requires your SBOM to be queryable against CVE databases

Neither CycloneDX nor SPDX is explicitly named in the regulation. Both satisfy these requirements. The decision comes down to which satisfies them better for your specific use case.

CycloneDX: The Security-First SBOM Format

CycloneDX was created by OWASP in 2017 specifically to address software supply chain security. It is now maintained as an independent OWASP standard with a governance model that includes representation from CISA, ENISA, and the German Federal Office for Information Security (BSI).

Current version: CycloneDX 1.6 (released late 2024)

Core Architecture

A CycloneDX SBOM has three primary sections:

• metadata — describes the SBOM itself: creation timestamp, tooling used, lifecycle stage (pre-build, build, post-build, operations), and the top-level component being described
• components — the inventory of all software components, each identified by package URL (PURL), version, license(s), and optional hash values (SHA-256, SHA-512)
• vulnerabilities — optionally embeds vulnerability data directly in the SBOM, or references external VEX documents

The VEX Advantage for CRA Art.14

The most significant CycloneDX differentiator for CRA compliance is native VEX (Vulnerability Exploitability eXchange) support. VEX is a structured format for asserting whether a specific vulnerability in a known component is:

• Exploitable — the vulnerability is present and reachable
• Not affected — the vulnerable code path is not reachable in your product
• Fixed — you have applied a remediation
• Under investigation — you are assessing exploitability

For CRA Art.14 compliance, where you must demonstrate active vulnerability management, a CycloneDX SBOM with embedded VEX statements gives market surveillance authorities a single document showing both the component inventory and your vulnerability triage decisions. This is significantly stronger than an SBOM list with a separate vulnerability spreadsheet.

CycloneDX and ENISA

ENISA's 2024 guidance on software supply chain security explicitly references CycloneDX as a recommended format for vulnerability disclosure workflows. The BSI (Germany) has integrated CycloneDX into its CSAF (Common Security Advisory Framework) tooling. If your customers include German federal agencies or critical infrastructure operators, CycloneDX documentation is increasingly expected.

Serialisation Options

CycloneDX 1.6 supports:

• JSON — recommended for API-driven pipelines and CI/CD integration
• XML — required for CSAF compatibility and some procurement workflows
• Protobuf — for high-volume automated processing (uncommon in compliance contexts)

Recommendation: CycloneDX 1.6 JSON for the SBOM file you store and distribute. Generate XML in parallel if you have CSAF requirements.

SPDX: The License-First SBOM Format

SPDX (Software Package Data Exchange) was created by the Linux Foundation in 2010 and became ISO/IEC 5962:2021. Its design priority is license compliance — tracking FOSS licenses across complex dependency trees for legal review.

Current version: SPDX 3.0 (released 2024)

Core Architecture

SPDX 3.0 restructured the format significantly from SPDX 2.x. It uses a profile system:

• Core profile — basic package identification and relationships
• Software profile — source code, packages, files
• Security profile — vulnerability information (added in 3.0)
• Licensing profile — detailed license expressions (SPDX's original strength)

Where SPDX Excels

SPDX has deeper ecosystem integration in two specific areas:

1. Open source license compliance — SPDX expressions (GPL-2.0-only AND MIT) are the industry standard for license identification and are used natively by GitHub's dependency graph, REUSE (FSFE), and most legal compliance tooling
2. Git repository integration — SPDX files can represent not just packages but individual files with per-file license headers, useful for source-level audits

SPDX 3.0 Security Profile vs. CycloneDX VEX

SPDX 3.0 added a security profile that provides vulnerability tracking capabilities. However, as of 2026, VEX tooling is more mature in the CycloneDX ecosystem. Most CSAF-to-VEX conversion tools target CycloneDX output, and automated VEX generation in CI/CD pipelines is primarily CycloneDX-based.

For pure license compliance workflows (particularly if you need to share SBOM data with open-source legal teams or your procurement chain requires license attestation), SPDX's license handling remains more granular.

CRA Compliance Matrix: CycloneDX 1.6 vs SPDX 3.0

Summary: CycloneDX 1.6 wins for CRA security obligations. SPDX 3.0 wins for license compliance workflows. For most SaaS developers, the CRA security requirements are the primary driver.

Recommended Tools by Format

CycloneDX Generation

Syft (Anchore) — The most widely deployed SBOM generator. Generates CycloneDX 1.6 JSON from container images, directories, source repos, and lock files. Runs in CI/CD with no external dependencies:

syft /path/to/project -o cyclonedx-json > sbom.cdx.json
syft container:myapp:latest -o cyclonedx-json > sbom-container.cdx.json

cdxgen (OWASP) — The official OWASP CycloneDX generator. Supports 20+ languages and build systems natively, including Go modules, Python requirements, npm, Maven, Gradle, Rust Cargo:

cdxgen -t java . -o sbom.json
cdxgen -t python . -o sbom.json

Trivy (Aqua Security) — Multi-purpose scanner that generates CycloneDX SBOMs as a byproduct of vulnerability scanning:

trivy sbom --format cyclonedx --output sbom.json .

CycloneDX CLI (OWASP) — Validates, merges, and converts CycloneDX SBOMs. Essential for pipeline automation:

cyclonedx-cli validate --input sbom.cdx.json --fail-on-errors
cyclonedx-cli merge --input-files sbom-app.json sbom-deps.json --output-file sbom-merged.json

SPDX Generation

spdx-sbom-generator (Linux Foundation) — Generates SPDX 2.3 SBOMs from 11 package managers.

TERN (VMware/Broadcom) — Container image SBOM generation in SPDX format. Strong for layer-by-layer analysis.

FOSSology — Enterprise-grade license compliance scanner that outputs SPDX. Used in automotive and industrial embedded contexts.

Cross-Format Tools

SBOM Scorecard (OpenSSF) — Evaluates SBOM quality against a rubric. Accepts both CycloneDX and SPDX. Run this against your SBOMs before submitting to market surveillance authorities.

Grype (Anchore) — Vulnerability scanner that consumes CycloneDX or SPDX SBOMs and enriches them with CVE data. Critical for demonstrating Art.14 active monitoring.

grype sbom:./sbom.cdx.json --output json > vulnerability-report.json

The Hybrid Strategy for Enterprise Environments

For teams with complex procurement or open-source compliance requirements, generating both formats from a single pipeline is practical:

# GitHub Actions example
- name: Generate CycloneDX SBOM (CRA compliance)
  run: syft . -o cyclonedx-json > sbom.cdx.json

- name: Generate SPDX SBOM (license compliance)
  run: syft . -o spdx-json > sbom.spdx.json

- name: Validate CycloneDX SBOM
  run: cyclonedx-cli validate --input sbom.cdx.json --fail-on-errors

- name: Scan for vulnerabilities
  run: grype sbom:./sbom.cdx.json --output json > vuln-report.json

- name: Archive SBOMs
  uses: actions/upload-artifact@v4
  with:
    name: sbom-artifacts
    path: |
      sbom.cdx.json
      sbom.spdx.json
      vuln-report.json

Store both. Publish CycloneDX for security-focused recipients (market surveillance, CERT coordination, customers asking about CRA compliance). Share SPDX with legal teams and open-source compliance workflows.

Storage and Retention Requirements

Art.31 requires technical documentation to be retained for at least ten years after the product is placed on the market or after the end of the supported lifecycle (whichever is later). Your SBOM storage strategy must account for this:

1. Version-lock SBOMs — generate a new SBOM at each release, tagged with the product version and build hash. Do not overwrite previous versions.
2. Immutable storage — use content-addressable storage (Git LFS, object storage with versioning) rather than mutable file paths
3. EU-resident storage for regulated products — if your product falls under CRA mandatory third-party assessment (Class I or Class II), consider the jurisdiction of your SBOM storage. SBOM files can contain vulnerability information that, under CLOUD Act, could be accessible to US law enforcement if stored on AWS/Azure/GCP. EU-native object storage (Hetzner Object Storage, OVHcloud, Scaleway) eliminates this risk.

What's Next in This Series

Post #3 will cover CI/CD pipeline integration in depth: where in the pipeline to generate SBOMs, how to fail builds on SBOM validation errors, and how to automate the Art.14 vulnerability monitoring loop. We'll cover GitHub Actions, GitLab CI, and Jenkins pipelines with working YAML templates.

Post #4 addresses the vulnerability management obligation: how to map your CycloneDX SBOM against CVE databases continuously, generate VEX statements for false-positive management, and structure your Art.14 response workflow.

Post #5 delivers the complete CRA SBOM compliance stack: SBOM generation + vulnerability monitoring + VEX attestation + 10-year retention architecture, all deployable on EU-native infrastructure.

The sota.io EU CRA SBOM Developer Guide Series covers the full SBOM compliance lifecycle for the Cyber Resilience Act. Start from Post #1 for the regulatory foundation.