AA-sec logo AA-sec
SBOM

CycloneDX vs SPDX for CRA SBOMs: How to Choose the Right Format

CycloneDX and SPDX can both support CRA SBOM workflows. Compare their data models, lifecycle fit, tooling and interoperability before choosing a release format.

AA-sec29 August 2026
  • CRA SBOM format comparison CycloneDX SPDX
  • CycloneDX vs SPDX for CRA
  • CRA SBOM format
  • CycloneDX CRA
  • SPDX CRA
  • best SBOM format EU
Cover graphic comparing CycloneDX and SPDX as machine-readable SBOM formats for Cyber Resilience Act product-security workflows.

The Cyber Resilience Act (CRA) does not require manufacturers to choose CycloneDX or SPDX by name. It requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the product's top-level dependencies. The practical format question is therefore not “which standard is CRA compliant?” but which standard can your engineering and security workflow generate, exchange, validate and retain reliably for the exact product release?

CycloneDX and SPDX are both established machine-readable standards for software composition data. Both can represent much more than a flat list of package names. Their models, surrounding ecosystems and areas of emphasis differ, so the better choice depends on what information has to move between your build, vulnerability-management, licensing, procurement and evidence systems.

The CRA sets an outcome, not a preferred SBOM brand

Annex I Part II of Regulation (EU) 2024/2847 requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least top-level dependencies.

That wording creates several important boundaries for format selection:

  • the Regulation does not name CycloneDX or SPDX;
  • a valid CycloneDX or SPDX file is not automatically sufficient merely because it uses a recognised standard;
  • the SBOM still has to describe the relevant product and component scope accurately enough for the manufacturer's vulnerability-handling obligations;
  • the manufacturer remains responsible for the product-specific cybersecurity risk assessment, vulnerability decisions and technical documentation; and
  • format choice should support the evidence and operational workflows needed over the product lifecycle.

Article 13 also allows the European Commission to specify the format and elements of the SBOM by implementing acts in the future. That makes version control and standards monitoring part of a sensible long-term SBOM strategy. A team should be able to change its exchange profile without losing historical release evidence.

What CycloneDX is designed to represent

CycloneDX is a bill-of-materials standard maintained through the OWASP Foundation and Ecma International. Its current published specification is version 1.7, with JSON, XML and Protocol Buffers representations.

For software SBOM use, CycloneDX can model:

  • components and services;
  • direct and transitive dependency relationships;
  • package identifiers and component metadata;
  • licenses and copyright information;
  • hashes and other integrity information;
  • lifecycle and formulation information;
  • vulnerabilities and exploitability-related information through its broader BOM model; and
  • links between related BOMs and other supply-chain records.

Its model is strongly oriented toward software supply-chain and product-security workflows. That can make it a natural fit when the same SBOM has to feed software composition analysis, vulnerability triage, VEX-style status exchange, procurement checks or other security automation.

That is not a legal advantage under the CRA. It is an engineering characteristic: if your downstream security tools already consume CycloneDX well, using it can reduce the number of transformations between generation and vulnerability analysis.

What SPDX is designed to represent

SPDX is an open standard developed by the SPDX community under the Linux Foundation and standardised internationally; SPDX 2.2.1 is published as ISO/IEC 5962:2021. The current SPDX specification family also includes version 3.0.1.

SPDX 3.0.1 defines a broader data model for communicating bill-of-materials information. Its scope includes:

  • software composition;
  • package, file and snippet information;
  • build information;
  • creator, supplier and distributor identity;
  • provenance and integrity;
  • licenses and copyrights;
  • vulnerabilities, defects and other quality data;
  • relationships between system elements;
  • lifecycle and usage information; and
  • links between multiple SPDX documents.

SPDX also distinguishes SBOM types such as design, source, build, analysed, deployed and runtime SBOMs. That can be useful when an organisation needs to state explicitly which lifecycle perspective an inventory represents.

SPDX has deep roots in software licensing and open-source compliance, but current versions are not limited to licensing. For a manufacturer whose existing compliance, legal, package-governance or supplier processes already use SPDX, retaining one interoperable data model across those workflows may be more valuable than introducing a second format solely for CRA work.

Compare the workflow, not the feature checklist

A feature-by-feature comparison is useful only if it reflects what your actual tools support. Both specifications evolve, and a tool claiming “CycloneDX support” or “SPDX support” may implement only a subset of the current model.

Use the following questions as a decision framework rather than a universal ranking:

  • Build and generator support: for CycloneDX, verify that the release pipeline produces the required version directly and preserves dependency relationships. For SPDX, verify that the pipeline produces the required SPDX version with stable package and relationship data.
  • Vulnerability workflow: for CycloneDX, check whether vulnerability tools consume component identity, dependency context and related vulnerability or VEX data without lossy conversion. For SPDX, check whether the tools consume the software and security data you intend to exchange.
  • Licensing and legal metadata: for CycloneDX, confirm that the selected profile carries the license information your internal process requires. For SPDX, consider whether the organisation already depends on SPDX license, copyright, provenance or package-governance data.
  • Lifecycle perspective: for CycloneDX, confirm that consumers can understand whether the BOM represents source, build, analysed or deployed software. For SPDX, determine whether its SBOM types and build or lifecycle relationships map cleanly to your evidence model.
  • Downstream interchange: for either format, identify which customers, suppliers, scanners and repositories can consume the exact specification version you generate.
  • Validation: for either format, combine schema or specification validation with product-specific semantic checks rather than relying on syntax alone.
  • Long-term retention: for either format, preserve the original BOM, specification version, digest and release binding without rewriting historical evidence.

The right answer can differ between products inside the same company. A firmware team, a cloud-service team and a desktop-software team may have different build systems and downstream consumers. Standardising on one format can reduce operational complexity, but only if the chosen format works across those environments without destroying useful data.

Start with the consumers of the SBOM

A common mistake is to choose the format based on the generator alone. Generation is only the first step. The SBOM has to be consumed repeatedly throughout the support period.

List the systems and people that need the data:

  • software composition analysis and vulnerability tools;
  • product-security triage;
  • release gates;
  • procurement and supplier-management systems;
  • open-source and licensing review;
  • customer or regulator evidence packages;
  • incident-response workflows;
  • internal data lakes or asset inventories; and
  • long-term technical-documentation archives.

For every consumer, verify the exact specification versions it supports and which fields it actually uses. “Supports SPDX” is not enough if the tool accepts only SPDX 2.x tag/value while your pipeline emits an SPDX 3.0 serialization. “Supports CycloneDX” is not enough if dependency relationships or component identifiers are discarded on import.

Build a small interoperability test with a representative release. Generate the SBOM, import it into the real consumers and compare what comes out with what went in.

Preserve component identity before format-specific extras

For CRA vulnerability handling, reliable component identity is more important than choosing the richer-looking schema.

Whichever format you use, verify that the SBOM consistently preserves:

  • component name and version;
  • supplier or namespace information where relevant;
  • Package URL (PURL) or another suitable package identifier;
  • hashes when they are meaningful for the artifact;
  • stable internal references for dependency relationships;
  • direct dependencies required by the CRA baseline;
  • additional transitive dependencies where your workflow relies on them; and
  • the exact product, variant, release or artifact the SBOM describes.

If a conversion between formats turns a precise package coordinate into a generic name, drops dependency edges or loses the subject's release identity, the converted file may be less useful even though it still validates syntactically.

Do not treat conversion as a substitute for validation. Compare component counts, identifiers, relationships, lifecycle metadata and any security or license fields your downstream decisions depend on.

Decide whether one canonical format or two outputs is safer

There are three common operating models.

One canonical format

The build produces one authoritative SBOM format, and all internal systems consume it directly.

This is the simplest model when the toolchain is aligned. It reduces transformation logic and makes historical reproduction easier because there is one release SBOM and one digest to retain.

One canonical format plus derived exports

The build retains one authoritative SBOM, then converts it to another format for a specific customer or downstream system.

This can work well when the derived format is treated as an exchange artifact rather than a second source of truth. Retain the conversion tool and version, the source SBOM digest, the derived output digest and validation results so later reviewers can reconstruct the transformation.

Two native outputs

The pipeline generates both CycloneDX and SPDX directly from the same controlled build inputs.

This can be appropriate when different consumers require different formats and a conversion would lose important semantics. It also creates more evidence to govern. The two outputs should identify the same release and their differences should be explainable rather than silently accepted.

Avoid maintaining two manually edited SBOMs. If the files diverge because humans correct them independently, later vulnerability analysis may depend on which copy a tool happened to ingest.

Do not confuse format version with SBOM quality

Choosing a current specification version can unlock useful fields, but it does not guarantee completeness or accuracy.

A high-quality release SBOM still needs:

  • a clearly identified subject;
  • a declared generation perspective;
  • stable component identity;
  • dependency relationships that reflect the declared scope;
  • known limitations or exclusions;
  • validation against the selected specification;
  • release binding to an immutable artifact or equivalent identifier; and
  • retained generation and validation evidence.

The CRA minimum of top-level dependencies does not prevent a manufacturer from retaining richer transitive information when that is useful for vulnerability handling. Likewise, a large transitive inventory is not automatically better if component identities are ambiguous or the file cannot be tied to the shipped release.

Format selection and SBOM quality are separate decisions. First decide what evidence your product-security workflow needs; then verify that the chosen format and tools preserve that evidence reliably.

Use BSI TR-03183 as an implementation reference, not as a substitute for the CRA

BSI TR-03183 provides technical guidance for manufacturers and products under cyber-resilience requirements, with Part 2 dedicated to SBOMs. It is useful as a concrete engineering reference when defining an internal SBOM profile, required fields and validation rules.

Keep the legal boundary clear. The binding CRA requirement comes from Regulation (EU) 2024/2847. A technical guideline can help a team operationalise that requirement, but selecting a particular profile or passing a format validator does not by itself establish CRA conformity.

The same principle applies to specification conformance: a document can be valid CycloneDX or valid SPDX while still describing the wrong release, omitting components your declared process expects, or carrying ambiguous identities that undermine vulnerability analysis.

Make the decision reproducible

Document why the organisation selected a format instead of allowing it to become an undocumented historical accident.

A lightweight format decision record should capture:

  • selected standard and specification version;
  • supported serialization;
  • authoritative generation point in the lifecycle;
  • release subject and binding method;
  • mandatory identifiers and relationship data;
  • required downstream consumers;
  • validation tools and versions;
  • known unsupported or optional fields;
  • conversion rules, if any;
  • retention requirements;
  • owner for reviewing specification or regulatory changes; and
  • conditions that would trigger a format migration.

Review that decision when a generator changes, a major specification version is adopted, a critical consumer drops support, or the Commission specifies additional SBOM format or element requirements.

Plan migrations without rewriting historical evidence

If the organisation later moves from SPDX to CycloneDX or the other way around, preserve the original SBOMs for releases that were already approved.

For a new release, record the new standard and version as part of the generation evidence. If historical data must be converted for a new analysis tool, retain the original file and clearly identify the converted copy as derived data.

This distinction matters during vulnerability investigations. A converted historical SBOM may be useful operationally, but it should not be mistaken for the exact file that existed when the product was released.

Before migrating, run representative product inventories through both workflows and compare:

  • component identity;
  • direct and transitive dependencies;
  • package relationships;
  • licenses if they matter to the process;
  • vulnerability or exploitability status data if exchanged;
  • lifecycle and build metadata;
  • file hashes and external references; and
  • product/release subject identity.

Treat unexplained data loss as a migration finding, not as an acceptable side effect of changing formats.

Retain evidence about the format itself

For every approved release, preserve enough context to interpret the SBOM years later.

Useful records include:

  • the original SBOM file and digest;
  • CycloneDX or SPDX specification version;
  • serialization used;
  • generator and version;
  • generation configuration;
  • product, variant and release identity;
  • released artifact digest or equivalent immutable identifier;
  • validation result;
  • known limitations;
  • conversion provenance for derived copies; and
  • review decisions for material exceptions.

That evidence lets future reviewers distinguish a product change from a tooling change and understand what the SBOM could and could not represent at the time.

Choosing a format solves only the interchange layer. Teams still need each SBOM and its component identities, vulnerability decisions, validation results and release context to stay traceable as products change. AA-sec is designed around that lifecycle traceability between SBOM and component data, vulnerability work, security evidence and release decisions; it does not determine which format is legally sufficient or whether a product conforms to the CRA.

Key takeaway

Do not ask whether CycloneDX or SPDX is “the CRA format.” The CRA does not make that choice for manufacturers. Start with the product and release evidence you need, test the real systems that generate and consume the SBOM, choose a versioned profile that preserves that information, and validate the result against the exact software you ship.

If both formats work, prefer the option that reduces transformations and fits the organisation's existing engineering, security and governance systems. If different consumers genuinely require different representations, keep one authoritative source of truth or generate both outputs from the same controlled build—and retain enough provenance to explain the relationship between them.

Official sources