SPDX vs CycloneDX: Choosing the Right SBOM Format for Each Consumer

Most organisations pick an SBOM format once, by default, and only discover the cost when a customer, regulator or vulnerability platform asks for the other one and the converted file arrives with half its data missing. SPDX and CycloneDX both satisfy the "commonly used and machine-readable" bar that regulators set, and both can carry the minimum fields. They differ in their data models, in how they express licences, services and vulnerability status, and in what survives a round trip between them. This guide compares the two for supply chain, product security and procurement teams who must choose a primary format, decide when to produce both, and set conversion rules that do not quietly drop data. For SBOM fundamentals, generation and programme design, see the SBOM Guide; this page assumes you already produce SBOMs and focuses on the format decision.

Key takeaways

• Choose by consumer, not by preference. If a regulator, customer contract or platform names a format and version, produce exactly that; otherwise produce what your own vulnerability management stack ingests natively and treat the other format as an export.
• Licence compliance leans SPDX, security operations lean CycloneDX. SPDX grew from licence workflows and owns the SPDX License List that both formats use; CycloneDX grew from security tooling and models services, vulnerabilities and VEX states in one object model.
• Version matters as much as format. SPDX 3.0.1 is a different, RDF-based model from SPDX 2.3, and CycloneDX 1.7 adds fields older parsers reject. Confirm the version each consumer can parse before you switch.
• Conversion is lossy. Tool vendors state plainly that converting between non-native formats loses data; generate each required format from the build, not from the other format, and never chain conversions.
• Regulators set outcomes, not a winner. The EU Cyber Resilience Act, BSI TR-03183-2, CISA's minimum elements and US federal procurement all accept either format; the decision rests on data quality, identifiers and the consumers you serve.

What each format is

SPDX (System Package Data Exchange) is a Linux Foundation project. Its 2.2.1 edition is published as ISO/IEC 5962:2021, and the SPDX site lists 3.0 as the current specification, with 3.0.1 as the published document. SPDX 3 is built on an RDF data model: every piece of information is an element with an identifier, linked to other elements by typed relationships. The model is split into profiles (Core, Software, Security, Licensing, Dataset, AI, Build, Lite and others) and can be serialised in any RDF syntax, with a JSON-LD context for a simpler JSON form. SPDX 2.3 remains widely deployed, with JSON and tag-value encodings common in tooling.

CycloneDX is an OWASP project standardised by Ecma International Technical Committee 54 as ECMA-424. Version 1.7 was released on 21 October 2025. It is a single object model: a BOM document holds metadata, components, services, dependencies, compositions, vulnerabilities, formulation, declarations and related sections. The project also describes SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM, VDR, VEX and attestations, serialised as JSON, XML or Protocol Buffers.

Side-by-side comparison

Decision criteria: licence, security, VEX and services

Licence compliance versus security use case

If the main consumer is a legal or open source programme office checking obligations before distribution, SPDX is the natural fit. The SPDX License List (version 3.29.0, dated 16 September 2026) gives each licence a short identifier such as MIT or GPL-2.0-only, and SPDX licence expressions combine them, using WITH for exceptions and + for "or later". SPDX also separates the concluded licence from the declared one. CycloneDX uses the same identifiers and expressions, so the deciding factor is whether your legal tooling expects SPDX documents.

If the main consumer is a vulnerability management platform, a security operations team or a customer's third-party risk process, CycloneDX is often what the tooling ingests first.

VEX support

Both formats carry VEX, with different vocabularies. In CycloneDX 1.7 the analysis state is one of resolved, resolved_with_pedigree, exploitable, in_triage, false_positive or not_affected, and a not-affected justification is one of code_not_present, code_not_reachable, requires_configuration, requires_dependency, requires_environment, protected_by_compiler, protected_at_runtime, protected_at_perimeter or protected_by_mitigating_control. In SPDX 3 the VEX status is the relationship class itself (VexAffected, VexNotAffected, VexFixed, VexUnderInvestigation), and the justification vocabulary is componentNotPresent, vulnerableCodeNotPresent, vulnerableCodeCannotBeControlledByAdversary, vulnerableCodeNotInExecutePath and inlineMitigationsAlreadyExist. The two lists do not map one to one: CycloneDX's protection justifications are finer grained, and its false_positive state has no direct SPDX class. VEX can also travel in CSAF or OpenVEX; see the VEX Guide and the CSAF Security Advisories Guide.

Services and SaaS

If you sell a hosted service, or your product depends on third-party APIs, CycloneDX's services object records each endpoint, whether it requires authentication, its trust zone and the data classifications that flow to it. SPDX's software purpose vocabulary covers applications, libraries, containers, firmware, models and more, but has no service type, so a SaaS dependency in SPDX ends up as a package or an annotation. OMB M-26-05 says cloud platform contracts should require an SBOM of the runtime production environment on request, so service modelling matters for SaaS providers.

Tooling and parser support

Mainstream open source generators emit both formats; for example, Syft outputs CycloneDX and SPDX, and the CycloneDX CLI converts between CycloneDX encodings and SPDX JSON 2.3. Support for SPDX 3.0.1 JSON-LD is newer and less even across consumers than support for SPDX 2.3, so test every consumer before moving to 3.x. The SBOM operations guide covers ingestion and correlation.

What regulators and buyers accept

See the EU Cyber Resilience Act Guide and the US Federal Cybersecurity Executive Orders Guide; the Supplier SBOM Request Template has contract wording.

Minimum elements mapped to both formats

Where each format carries the main fields from the 2026 CISA Minimum Elements. A valid document can still leave them empty, so check your generator populates each one.

A component without a purl or CPE matches no vulnerability data, whatever the format. State completeness too: CycloneDX compositions marks an inventory complete or incomplete.

Threat model, failure modes and decision criteria by option

SPDX

Threat model. SPDX supports the same supply chain threats as any SBOM: known-vulnerable or abandoned components, dependencies replaced by malicious versions (ATT&CK T1195.001 Compromise Software Dependencies and Development Tools) and tampered builds (T1195.002 Compromise Software Supply Chain). Its particular strength is legal and provenance risk: shipping code under a licence you cannot meet, or losing track of which upstream inputs went into a release (the Build profile and hashes address this).

Architecture in words. A producer emits an SPDX document per release from the build pipeline: a root package with describes and dependsOn relationships down the dependency tree, a purl and hash per package, concluded and declared licences, and creation information naming the tool. Security data is either added in the Security profile (SPDX 3) or kept in a separate VEX document linked by identifier.

Failure modes. Moving to SPDX 3.0.1 while key consumers still parse only 2.3, so documents are rejected or silently misread; NOASSERTION in supplier and licence fields; and modelling hosted dependencies as packages, so a SaaS outage or breach does not appear in impact analysis.

Controls. Pin the SPDX version and encoding per consumer; validate every document against the official schema or SHACL shapes in CI; set a threshold for NOASSERTION on supplier and licence fields; generate from the built artefact, not the source manifest; and sign the document so recipients can check integrity.

Choose SPDX as primary when licence compliance and open source distribution drive the programme, your customers or distributions expect ISO/IEC 5962, or you need dataset and AI model descriptions in the same graph as your packages. See the SBOM vs AIBOM comparison for the AI fields.

CycloneDX

Threat model. CycloneDX covers the same component threats and adds visibility of services and data flows, so a compromised or failing third-party API shows up in impact analysis. Its vulnerability section addresses alert fatigue from unreachable findings and stale supplier disclosure.

Architecture in words. A producer emits a CycloneDX BOM per release with metadata.lifecycles set to the build phase, components with purl, hashes and licences, a dependencies graph keyed on bom-ref, and, for hosted products, services with endpoints and trust zones. VEX is published either inside the BOM's vulnerabilities section or as a separate VEX BOM that references the product BOM by serial number and version, so it can be updated daily without reissuing the inventory.

Failure modes. Embedding VEX in the inventory BOM, so every analysis change forces a new SBOM and consumers lose track of which is current; marking components not_affected without a justification, which recipients rightly ignore; generating 1.7 documents for a consumer that only validates 1.4 or 1.5; and setting compositions to complete when transitive dependencies were never resolved.

Controls. Separate inventory BOMs from VEX documents; require a justification on every not-affected statement; validate against the matching schema version in CI; set the lifecycle phase on every BOM; and populate services for every external API the product calls in production.

Choose CycloneDX as primary when security operations and vulnerability workflows drive the programme, you deliver SaaS, you need hardware, firmware or cryptographic inventories in the same model (see the Hardware and Firmware SBOM Guide), or your main consumers are security platforms.

Producing both

Generating both from one build serves mixed consumers; the risk is drift between generators, so compare component counts and purl sets on every release.

Conversion: where data is lost

Conversion tools exist and are useful for reading, but they are not a substitute for native generation. Anchore's Syft documentation states that "Converting between non-Syft formats loses data" and advises against chaining conversions such as SPDX to CycloneDX, because each step may lose format-specific data. The protobom project reads SPDX 2.2 to 3.0.1 and CycloneDX 1.2 to 1.7 into a neutral representation, but a target format still cannot hold a field it has no place for.

Rule: generate natively; if you must convert, convert once from the richest source, record the tool, and diff component counts before shipping.

Worked scenarios

Scenario 1: an EU device manufacturer preparing for the CRA. A manufacturer of connected industrial controllers has an open source office that has used SPDX 2.3 for licence review for years, and a product security team buying a vulnerability platform that ingests CycloneDX. Under Annex I Part II of the CRA it needs an SBOM covering at least top-level dependencies in its technical documentation. It keeps SPDX 2.3 JSON as the licence record, adds CycloneDX 1.6 output from the same build for the security platform (its platform does not yet validate 1.7), and uses the BSI TR-03183-2 field list as a completeness check for both. VEX is published separately, so the SBOM stays stable across a release while the vulnerability analysis changes weekly.

Scenario 2: a SaaS provider answering a federal customer. A US software company sells a hosted analytics platform to an agency whose contract, following OMB M-26-05, requires an SBOM of the runtime production environment on request. The provider chooses CycloneDX because its runtime depends on a managed database, an identity provider and two third-party APIs that belong in services, with authentication and data classification recorded. A first attempt converted an existing SPDX file and lost the service entries. The fix was to generate the CycloneDX BOM natively from deployment manifests, add services from the architecture register, set metadata.lifecycles to operations, and attach a VEX document explaining which scanner findings are not exploitable in the deployed configuration.

Where identity fits

A CycloneDX services entry marked authenticated points to an API key, OAuth client or service account that needs an owner in your machine identity inventory. SBOM signing keys and the CI tokens that publish SBOMs are non-human identities too. See the Securing the SBOM management platform itself guide.

Detection and measurement

• Schema validity rate: share of SBOMs that pass validation against the exact format version declared, per product line.
• Identifier coverage: share of components with a purl or CPE.
• Minimum field completeness: share of components with supplier, version, hash and licence populated (not NOASSERTION or empty).
• Cross-format drift: difference in component count and purl set between SPDX and CycloneDX outputs of the same build.
• Consumer rejection rate: SBOMs rejected or returned by customers, regulators or internal platforms, with the reason (version, encoding, missing field).
• VEX coverage: share of high and critical findings on shipped products with a published VEX status and justification within your service level.

Common failure patterns

• Choosing a format by tool default. Nobody checks what consumers can parse until the first rejection.
• Converting instead of generating. A converted file loses services, VEX states or licence detail, found only at audit.
• Upgrading versions unilaterally. Moving to SPDX 3.0.1 or CycloneDX 1.7 because it is newest, breaking consumers that validate older schemas.
• Valid but empty. Documents pass schema validation while supplier, licence and hash fields are blank or NOASSERTION, so they satisfy a checkbox and answer no question.
• VEX inside the inventory. Vulnerability analysis embedded in the SBOM forces reissue on every change and leaves consumers holding outdated status.
• Trusting an unsigned SBOM. A compromised build produces a convincing SBOM; generate and sign it inside a protected build, with provenance from the SLSA and Build Provenance Guide.

Framework mapping

Practitioner checklist

• List every SBOM consumer (customers, regulators, internal platforms) with the format, version and encoding each accepts.
• Pick a primary format from that list and the programme's main use case: licence compliance or security operations.
• Generate every required format natively from the build; ban chained conversions and record any single conversion in the output.
• Pin format versions per consumer and validate against the matching schema in CI, failing the build on errors.
• Check every minimum field in the mapping table is populated, with a purl or CPE and a hash on each component.
• Publish VEX separately from the inventory, with a justification on every not-affected statement.
• For hosted products, model external services, their authentication and data flows, and link them to the owning machine identities.
• Write the accepted format, version and delivery method into supplier contracts and review it when regulators publish implementing acts.

Standards and references

• SPDX: Specification 3.0.1
• OWASP CycloneDX: Specification Overview (ECMA-424)
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
• CISA and partner agencies: 2026 Minimum Elements for a Software Bill of Materials
• BSI: Technical Guideline TR-03183 Cyber Resilience Requirements
• OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
• SPDX: SPDX License List
• Anchore: Syft SBOM format conversion

Related NHI Mgmt Group resources: SBOM Guide · VEX Guide · SBOM vs AIBOM · EU Cyber Resilience Act Guide · SBOM vs HBOM vs CBOM