CycloneDX vs SPDX for Automotive: Choosing the Right SBOM Format

The Software Bill of Materials (SBOM) has rapidly transitioned from a niche software engineering practice to a regulatory requirement across the automotive industry. UNECE R155, ISO/SAE 21434, China’s GB 44495, and the EU Cyber Resilience Act all reference or mandate SBOM capabilities for managing software supply chain risk in connected vehicles. Yet the industry has not converged on a single SBOM format, and engineering teams must choose between two dominant standards: CycloneDX from OWASP and SPDX from the Linux Foundation.

This choice is not merely a technical formatting decision. The SBOM format you adopt determines your vulnerability management workflow, your supply chain transparency capabilities, your regulatory compliance evidence, and your integration options with downstream security tools. This article provides an in-depth, automotive-focused comparison to help engineering teams make an informed decision.

Origins and Governance

SPDX: The License Compliance Pioneer

The Software Package Data Exchange (SPDX) specification originated in 2010 under the Linux Foundation. Its initial focus was on software license compliance — tracking which open-source licenses apply to which components in a software distribution. Over the years, SPDX evolved to include security-relevant fields and broader software composition data. In 2021, SPDX achieved ISO/IEC 5962:2021 standardization, making it the first SBOM format recognized as an international standard.

SPDX governance follows the Linux Foundation’s community-driven model with working groups for different aspects of the specification. The license-centric heritage remains visible in SPDX’s rich license expression syntax and extensive license list, which are unmatched by any other SBOM format. SPDX 3.0, released in 2024, introduced a modular profile system (Core, Software, Security, Licensing, AI, Dataset) that significantly expanded the format’s capabilities beyond its license compliance roots.

CycloneDX: Security-First Design

CycloneDX was created by OWASP (Open Worldwide Application Security Project) in 2017, specifically designed as a security-oriented bill of materials format. Unlike SPDX’s evolution from license compliance, CycloneDX was built from the ground up to support vulnerability identification, risk assessment, and security tool integration. Its design philosophy prioritizes simplicity and actionability for security workflows.

CycloneDX governance sits within the OWASP Foundation, with rapid release cycles driven by the security community’s evolving needs. The format reached version 1.6 in 2024, adding capabilities for hardware bill of materials (HBOM), manufacturing bill of materials (MBOM), and attestation workflows. CycloneDX was recognized as an Ecma International standard in 2024, providing it with formal standardization backing.

Schema and Data Model Comparison

SPDX Data Model

SPDX 3.0 uses a graph-based data model built around Elements and Relationships. Every entity in an SPDX document is an Element (packages, files, snippets), and relationships between elements are expressed as typed edges in the graph. This model is highly flexible and can represent complex dependency trees, build chains, and distribution hierarchies. SPDX supports multiple serialization formats: JSON-LD, RDF/XML, tag-value, spreadsheet (XLSX), and YAML.

The graph model excels at representing the complex, multi-layered relationships found in automotive software stacks. An AUTOSAR Classic Platform ECU, for example, might have OS-level packages containing libraries that depend on other packages, with specific files within those packages covered by different licenses. SPDX’s element-relationship model can capture all of these relationships precisely.

CycloneDX Data Model

CycloneDX uses a hierarchical, component-based model. A BOM contains components, and components can contain nested sub-components (forming a dependency tree). Each component has properties including name, version, type, supplier, hashes, licenses, and external references. CycloneDX supports JSON and XML serialization, with Protocol Buffers (protobuf) added in version 1.6 for high-performance use cases.

The hierarchical model maps naturally to how automotive suppliers deliver software: a Tier-1 delivers an ECU software package containing AUTOSAR BSW modules, application SWCs, and configuration data. Each of these contains sub-components with their own dependencies. CycloneDX’s nesting model represents this delivery structure intuitively.

Vulnerability and VEX Handling

CycloneDX Vulnerability Support

CycloneDX has native, first-class support for vulnerability data within the BOM itself. The vulnerabilities array allows embedding CVE references, severity scores (CVSS v2, v3.1, v4.0), affected version ranges, and remediation information directly in the SBOM. This tight integration means a single CycloneDX document can serve as both an inventory and a vulnerability report.

CycloneDX’s VEX (Vulnerability Exploitability eXchange) support is equally native. VEX statements are expressed as vulnerability analysis entries within the BOM, using four status values: not_affected, affected, fixed, and under_investigation. Each status can include a justification (e.g., code_not_reachable, vulnerable_code_not_in_execute_path) that explains why a component with a known CVE is not actually exploitable in the specific deployment context. For automotive, this is critical: an ECU running Linux may include a kernel version with known CVEs, but if the affected subsystem is not compiled into the automotive build, VEX documents that non-exploitability.

SPDX Vulnerability Support

SPDX 3.0 introduced the Security Profile, which adds vulnerability and VEX capabilities to the specification. Prior to 3.0, SPDX had no native security data support, and vulnerability information had to be managed in separate systems and correlated by package identifiers. The Security Profile brings SPDX closer to parity with CycloneDX for vulnerability management, but the ecosystem of tools supporting these new fields is still maturing.

SPDX’s VEX implementation follows the CISA VEX specification more closely than CycloneDX, using a document-centric approach where VEX information is captured in separate SPDX documents that reference the original SBOM. This separation has the advantage of allowing VEX updates without modifying the base SBOM, but adds complexity in tooling that must correlate multiple documents.

Automotive-Specific Features

Hardware Bill of Materials

Automotive cybersecurity extends beyond software. ECU hardware components (microcontrollers, HSMs, cryptographic accelerators, network interface controllers) have their own security properties and vulnerabilities. CycloneDX 1.5+ introduced explicit device and hardware component types, enabling a combined software-hardware BOM. This is particularly relevant for automotive systems where hardware security features (hardware security modules, secure boot ROM, trusted execution environments) directly affect the attack surface.

SPDX 3.0’s flexible element model can represent hardware components, but there is no standardized hardware profile yet. Teams using SPDX for hardware inventory must define their own conventions, which limits interoperability with supply chain partners.

Firmware and Binary Analysis

Automotive ECU software is often delivered as compiled binaries rather than source packages. Both formats support binary component identification through cryptographic hashes (SHA-256, SHA-512) and Package URLs (purl). CycloneDX additionally supports the evidence field, which can record how a component was identified (e.g., through binary analysis, SCA tool, or supplier attestation). This provenance tracking is valuable in automotive supply chains where Tier-2 and Tier-3 supplier transparency is limited.

Supplier and Manufacturing Data

CycloneDX 1.5 introduced manufacturer and supplier fields at the component level, along with a formulation section for capturing build environment details. For automotive OEMs managing hundreds of suppliers, this allows tracking not just what software is in a vehicle but who supplied it, how it was built, and what tools were used in the build process. SPDX captures supplier information through the supplier property on packages, but the build environment details require custom extensions.

Detailed Feature Comparison

The following table compares CycloneDX and SPDX across the most important dimensions for automotive SBOM use cases.

Feature	CycloneDX (1.6)	SPDX (3.0)
Governance	OWASP Foundation / Ecma International	Linux Foundation / ISO 5962
Primary Focus	Security and risk management	License compliance and software composition
ISO Standardization	Ecma-424 (2024)	ISO/IEC 5962:2021
Data Model	Hierarchical component tree	Graph-based elements and relationships
Serialization Formats	JSON, XML, Protocol Buffers	JSON-LD, RDF/XML, Tag-Value, YAML, XLSX
Native Vulnerability Support	Yes (first-class vulnerabilities array)	Yes (Security Profile in 3.0, limited in 2.3)
VEX Support	Native inline VEX with justification codes	Separate VEX documents per CISA spec
License Expression	SPDX license expression syntax (adopted)	Native SPDX license expression (most comprehensive)
Hardware BOM (HBOM)	Native device/hardware component types	Possible via custom elements, no standard profile
Build Environment Capture	Formulation section with build tools, environments	Build Profile in 3.0 (emerging)
Supplier/Manufacturer Fields	Component-level manufacturer and supplier	Package-level supplier; organization entities
Package URL (purl)	Full support	Full support
Cryptographic Hashes	SHA-256, SHA-512, SHA3, BLAKE3, and more	SHA-256, SHA-512, SHA3, MD5, and more
Dependency Relationships	Component nesting and dependencies array	Typed relationship edges (DEPENDS_ON, etc.)
Services and APIs	Native services section for API/endpoint inventory	No standard service representation
Attestation/Compliance	Declarations and attestation workflows (1.6)	Annotations and review metadata
Tool Ecosystem Size	Large (400+ tools as of 2026)	Large (350+ tools as of 2026)
Automotive Tool Support	Growing (ThreatZ, Black Duck, Synopsys)	Established (SW360, FOSSology, ThreatZ)

Regulatory Alignment

UNECE R155 and WP.29

UNECE R155 requires OEMs to demonstrate a Cyber Security Management System (CSMS) that includes processes for managing software supply chain risks. While R155 does not mandate a specific SBOM format, the associated guidance documents reference SBOM as a key evidence artifact. Both CycloneDX and SPDX are accepted by type approval authorities, but the choice affects how easily you can demonstrate compliance.

R155 Annex 5 lists threat categories including “threats to vehicles regarding their software update procedures” and “threats to vehicles regarding their external connectivity.” Demonstrating mitigation of these threats requires tracing software components to known vulnerabilities and showing that exploitable vulnerabilities are addressed. CycloneDX’s integrated vulnerability and VEX data makes this traceability straightforward in a single document. SPDX achieves the same result but requires correlating the SBOM with separate vulnerability and VEX documents.

China GB 44495

China’s national standard GB 44495 for automotive cybersecurity mirrors many R155 requirements but adds specific provisions for software supply chain management relevant to the Chinese market. The standard emphasizes traceability of all software components, including open-source libraries, commercial components, and in-house developed code. Both SBOM formats satisfy these requirements, but SPDX’s ISO standardization status provides an additional compliance advantage in regulatory environments that prefer ISO-referenced standards.

EU Cyber Resilience Act (CRA)

The EU CRA, which applies to products with digital elements including automotive components, explicitly mandates SBOM delivery. The CRA references both CycloneDX and SPDX as acceptable formats in its technical guidance. Notably, the CRA requires vulnerability handling processes that include timely disclosure and remediation. CycloneDX’s native vulnerability and VEX integration aligns well with these requirements, reducing the number of separate documents and processes needed for compliance.

US Executive Order 14028

While primarily targeting federal software procurement, EO 14028 and the subsequent NTIA minimum elements for SBOMs established baseline requirements that have influenced automotive SBOM practices globally. The minimum elements (supplier name, component name, version, unique identifiers, dependency relationships, author, timestamp) are fully supported by both CycloneDX and SPDX. Automotive companies with US government contracts or US-market vehicles benefit from aligning with these minimum elements regardless of format choice.

Tooling Ecosystem

Generation Tools

Both formats are well-supported by Software Composition Analysis (SCA) tools. Synopsys Black Duck, Snyk, FOSSA, and Sonatype Nexus all generate both CycloneDX and SPDX. For automotive-specific tooling, AUTOSAR tool chains (Vector DaVinci, ETAS ISOLAR) are increasingly adding SBOM export capabilities, with CycloneDX JSON being the most commonly supported output format due to its simpler schema.

For binary analysis (critical in automotive where source code is often unavailable), tools like Binary Analysis Next Generation (BANG), CodeSentry, and Binwalk support both formats for component identification results. CycloneDX’s evidence field provides a standardized way to indicate that components were identified through binary analysis rather than source-level SCA, which is important for confidence assessment.

Consumption and Analysis Tools

Vulnerability correlation tools (Dependency-Track, Grype, Trivy) have historically favored CycloneDX due to its native vulnerability data model. Dependency-Track, OWASP’s own vulnerability management platform, was designed for CycloneDX and provides the most complete workflow for that format. SPDX support in these tools exists but is often limited to component inventory ingestion, with vulnerability data managed separately.

License compliance tools naturally favor SPDX. FOSSology, SW360, and license scanning tools in CI/CD pipelines provide the richest experience with SPDX’s license expression syntax. For automotive teams that must manage both license compliance (for open-source governance) and vulnerability management (for cybersecurity compliance), this creates pressure to maintain SBOMs in both formats or to choose a platform that bridges the gap.

Conversion and Interoperability

Format conversion tools exist (CycloneDX CLI, SPDX tools, Protobom), but conversion is inherently lossy. CycloneDX vulnerability data has no direct equivalent in SPDX 2.3 and maps imperfectly to SPDX 3.0 Security Profile. SPDX’s rich relationship types (DESCRIBED_BY, BUILD_TOOL_OF, PREREQUISITE_FOR) have no direct CycloneDX equivalent. Teams should standardize on one primary format and convert only when supply chain partners require the alternate format.

When to Use CycloneDX

CycloneDX is the stronger choice when your primary SBOM use case is security and vulnerability management. Specifically, consider CycloneDX when:

• Vulnerability management is the primary driver: Your organization needs to track, triage, and remediate vulnerabilities across your vehicle software supply chain. CycloneDX’s native vulnerability and VEX support minimizes tooling friction.
• You need combined software and hardware BOM: Automotive systems with significant hardware security dependencies benefit from CycloneDX’s native HBOM capabilities to track HSM firmware, microcontroller revisions, and hardware security features alongside software.
• Your supply chain uses OWASP tooling: If your vulnerability management workflow centers on Dependency-Track or other OWASP ecosystem tools, CycloneDX provides the smoothest integration.
• VEX is critical to your workflow: Automotive ECUs often contain Linux kernels or other large packages with many CVEs, most of which are not exploitable in the automotive deployment context. CycloneDX’s inline VEX reduces the burden of managing separate VEX documents.
• You need to document build provenance: CycloneDX’s formulation section captures the complete build environment, supporting supply chain integrity verification requirements.

When to Use SPDX

SPDX is the stronger choice when license compliance is a primary concern alongside security, or when formal standardization is important. Consider SPDX when:

• License compliance is a co-equal priority: Automotive software stacks combine code under GPL, LGPL, Apache, MIT, proprietary, and custom licenses. SPDX’s license expression syntax is the industry standard for expressing complex license conditions and is referenced by both CycloneDX and other tools.
• Regulatory environments prefer ISO standards: In markets where regulators explicitly reference ISO standards, SPDX’s ISO/IEC 5962 status provides a formal compliance advantage.
• Complex dependency relationships matter: SPDX’s typed relationship model can express nuanced dependency semantics (build-time vs. runtime dependencies, optional vs. required, static vs. dynamic linking) that are important for accurate vulnerability impact analysis.
• Your organization uses Linux Foundation tooling: If your open-source program office uses FOSSology, SW360, or ClearlyDefined, SPDX provides native integration.
• Multi-format document graphs: SPDX 3.0’s profile system allows a single document graph to serve licensing, security, AI, and build use cases through profile-specific elements.

Hybrid Approaches

Many automotive organizations find that neither format alone satisfies all their needs. Several hybrid strategies have emerged in practice.

Primary Format with Conversion

Standardize on one format internally (usually CycloneDX for security-focused teams or SPDX for compliance-focused teams) and convert to the other format when required by supply chain partners or regulatory bodies. This approach minimizes internal tool complexity at the cost of potential data loss during conversion. Maintain a validation step after conversion to verify that critical fields survived the transformation.

Purpose-Driven Format Selection

Use CycloneDX for vulnerability management and security operations workflows. Use SPDX for license compliance and open-source governance. Maintain both SBOMs from the same source data, ensuring consistency. This approach adds maintenance overhead but provides the best tool integration for each use case. Automated generation from a shared component database eliminates most of the synchronization burden.

Unified Platforms

Platforms like ThreatZ abstract the format choice by maintaining an internal component model that can export to either format. Teams work with a normalized view of their software inventory and generate CycloneDX or SPDX outputs as needed for different stakeholders. This is increasingly the preferred approach for large automotive organizations managing hundreds of ECUs across multiple vehicle platforms.

How ThreatZ Supports Both Formats

ThreatZ was designed with the understanding that the SBOM format landscape is plural and that automotive organizations need flexibility. The platform provides comprehensive support for both CycloneDX and SPDX throughout the SBOM lifecycle.

Multi-Format Import

ThreatZ ingests SBOMs in CycloneDX (JSON, XML) and SPDX (JSON, tag-value, RDF) formats, normalizing them into a unified component graph. This means Tier-1 suppliers can deliver SBOMs in whichever format their tooling generates, and the OEM can manage a consistent inventory regardless of supplier format choices. Import validation checks for minimum required fields, hash integrity, and schema compliance.

Vulnerability Correlation Across Formats

Regardless of input format, ThreatZ correlates all components against multiple vulnerability databases (NVD, OSV, GitHub Advisory, automotive-specific feeds) using Package URLs and CPE identifiers. VEX data from CycloneDX documents is imported natively. For SPDX inputs without VEX, ThreatZ enables analysts to create VEX statements within the platform and export them in either format.

Flexible Export

ThreatZ generates SBOMs in both CycloneDX 1.5/1.6 and SPDX 2.3/3.0 formats, including full vulnerability data, VEX statements, and supplier information. Export profiles can be customized for different recipients: a detailed internal SBOM with vulnerability data for the security team, a license-focused SPDX export for the legal team, and a minimal CycloneDX export for regulatory submission. All exports include cryptographic signing for integrity verification.

SBOM Lifecycle Management

ThreatZ tracks SBOM versioning across software releases, enabling teams to diff SBOMs between releases and understand exactly which components were added, removed, or updated. This lifecycle tracking operates at the format-agnostic component level, meaning version comparisons work regardless of whether the original SBOMs were in CycloneDX or SPDX. Automated alerts notify teams when newly disclosed vulnerabilities affect components in any active SBOM.

Making the Decision

For automotive teams starting their SBOM journey in 2026, the practical recommendation is:

1. Default to CycloneDX if your primary use case is cybersecurity vulnerability management and ISO/SAE 21434 / R155 compliance. Its security-native design, integrated VEX support, and HBOM capabilities align with automotive cybersecurity engineering workflows.
2. Default to SPDX if your organization has established open-source program offices with existing SPDX tooling, or if your regulatory environment specifically references ISO/IEC 5962.
3. Plan for both regardless of your primary choice. The automotive supply chain is heterogeneous, and you will inevitably receive and need to produce SBOMs in both formats. Invest in a platform that normalizes across formats rather than building format-specific workflows.

The format war between CycloneDX and SPDX is gradually resolving through convergence: SPDX 3.0 adopted security capabilities, CycloneDX adopted SPDX license expressions, and both communities collaborate on shared identifiers (purl, CPE). The long-term trajectory is toward interoperability rather than winner-take-all, and automotive teams that maintain flexibility will be best positioned as the landscape evolves.

Key Takeaways

• CycloneDX (OWASP) is security-first with native vulnerability, VEX, and HBOM support. SPDX (Linux Foundation) excels at license compliance with ISO standardization.
• Both formats satisfy the SBOM requirements of UNECE R155, ISO/SAE 21434, GB 44495, and EU CRA. Format choice affects workflow efficiency, not regulatory acceptability.
• CycloneDX’s inline VEX is simpler for automotive teams managing high CVE counts against Linux-based ECU stacks. SPDX’s separate VEX documents offer update flexibility.
• Automotive teams should plan for both formats given supply chain heterogeneity, using a platform that normalizes across formats.
• Conversion between formats is possible but lossy. Standardize on one primary format and validate all conversions.
• ThreatZ supports full import, correlation, VEX management, and export for both CycloneDX and SPDX formats.