Understanding SPDX vs CycloneDX

When federal agencies and defense contractors began taking software supply chain risk seriously, one of the first practical questions was straightforward: what format do we actually use to document what’s in the software? That question has never had a single clean answer, and it still doesn’t. Two formats have emerged as the dominant standards — SPDX and CycloneDX — and both are widely referenced in federal guidance, vendor documentation, and acquisition language. Understanding what separates them, where each one excels, and how each one holds up under real operational pressure is not an academic exercise. It is a practical requirement for any organization trying to build a defensible, maintainable SBOM program.

The National Telecommunications and Information Administration (NTIA) played a significant role in shaping federal expectations around SBOM adoption. NTIA’s minimum elements guidance, published in 2021, established a baseline for what a software bill of materials should contain but deliberately remained format-agnostic. It identified the data fields that matter — supplier name, component name, version, component identifiers, dependency relationships, SBOM author, and timestamp — without mandating that organizations use any specific schema to carry that data. That decision gave the ecosystem room to mature, but it also left federal programs to sort out format selection on their own, often without clear guidance from their authorizing officials or contracting officers.

The result is that most federal environments today are not committed to a single format. They are accumulating SBOMs in whatever format vendors happen to produce, which means a program office might receive SPDX from one contractor and CycloneDX from another. Without a deliberate strategy for handling both, SBOM data becomes difficult to aggregate, compare, or act on. That is the operational reality driving format selection decisions right now — not theoretical elegance, but practical workflow compatibility.

This article is written for the people making those decisions: ISSOs working through authorization packages, enterprise architects building ingestion pipelines, program managers negotiating SBOM deliverable language in contracts, and engineers trying to understand which tooling actually supports which format. The goal is not to declare a winner. Both formats are legitimate, both are actively maintained, and both satisfy federal minimum element requirements when implemented correctly. The goal is to give you enough operational understanding to make a deliberate choice rather than an accidental one.

Before getting into the comparison, it is worth anchoring this discussion to the broader purpose of SBOM programs. A software bill of materials (SBOM) is only as useful as the workflows it enables — vulnerability identification, license compliance, dependency tracking, and incident response. Format selection affects all of those workflows, which means the right answer depends heavily on what your organization is actually trying to do with the data after it arrives.

What SPDX Is and Where It Came From

SPDX stands for Software Package Data Exchange. It originated in the open source community in 2010, driven by a practical problem that legal and compliance teams at large software companies were running into daily: there was no consistent way to communicate software license information across organizational boundaries. If one company consumed an open source component from another, there was no standardized format for expressing what license applied to that component, what its provenance was, or how it related to other packages in a larger system. SPDX was created to solve that problem.

The Linux Foundation hosts the SPDX project, and it became an ISO/IEC international standard — ISO 5962 — in 2021. That standardization milestone matters in federal contexts where procurement language and authorization requirements often reference ISO standards as indicators of maturity. SPDX has been through multiple specification versions, with SPDX 2.3 being the most widely deployed and SPDX 3.0 introducing a more modular profile-based structure designed to accommodate a broader range of use cases including AI and hardware components.

The core strength of SPDX is its license expression language. SPDX defines a structured, machine-readable syntax for expressing complex license conditions — including SPDX license identifiers, license exceptions, AND/OR combinations, and custom licenses not in the SPDX license list. For organizations with legal review requirements, license obligation tracking, or open source governance programs, that expressiveness is practically irreplaceable. No other SBOM format handles license data with the same precision.

SPDX also has a strong model for provenance documentation — tracking where a component came from, how it was modified, who verified it, and what relationship it has to other elements in the package. This makes SPDX particularly well-suited for software supply chain transparency use cases where you need to answer not just “what is in this software” but “where did each piece come from and who vouches for it.” For defense programs with supply chain integrity requirements, that provenance chain carries real operational weight.

SPDX supports multiple serialization formats: tag-value (a human-readable flat text format), JSON, YAML, RDF, and XML. The tag-value format is widely used in tooling output and is readable by engineers without specialized parsers, which has practical advantages in environments where tooling support is uneven or where manual review is part of the process. The JSON format is the most common choice for automated ingestion pipelines.

What CycloneDX Is and Where It Came From

CycloneDX was created by OWASP — the Open Web Application Security Project — and first published in 2017. Unlike SPDX, which grew out of licensing and compliance concerns, CycloneDX was designed from the ground up with security use cases as the primary driver. The people building it were thinking about vulnerability management, software supply chain risk, and component transparency in the context of application security practice — not legal review. That design heritage shows up clearly in the format’s feature set.

CycloneDX natively supports concepts that SPDX originally did not have or handled only partially. Vulnerabilities can be embedded directly in a CycloneDX document, allowing a single artifact to carry both the component inventory and known vulnerability data associated with those components. Services — not just software packages — can be enumerated, which matters for microservice architectures and cloud-native environments where the risk surface extends beyond compiled binaries. Hardware components are supported as a distinct element type, which has obvious relevance for defense programs dealing with embedded systems, firmware, and OT environments where hardware and software cannot be cleanly separated.

CycloneDX also supports the concept of a Vulnerability Exploitability eXchange (VEX) document as an extension of the SBOM, allowing organizations to communicate not just that a vulnerability exists in a component but whether that vulnerability is actually exploitable in a given deployment context. VEX is increasingly important in federal environments where raw vulnerability counts from automated scanners generate noise that overwhelms triage capacity. The ability to attach authoritative exploitability status to SBOM data helps organizations prioritize remediation against real operational risk rather than theoretical exposure.

The current CycloneDX specification version as of this writing is 1.6, which introduced support for machine learning model bill of materials (ML-BOM) concepts — a capability that is beginning to attract attention as federal agencies grapple with AI system transparency requirements. CycloneDX serialization is primarily JSON and XML, with JSON being the dominant format in modern tooling. The format is maintained by OWASP and has broad adoption in commercial security tooling, particularly static analysis, software composition analysis, and container scanning platforms.

From a practical tooling standpoint, CycloneDX has strong support in the developer security tooling ecosystem. Many of the tools federal programs are already using for software composition analysis produce CycloneDX output natively or as a primary export format. That means in environments where SBOM generation is happening at the CI/CD pipeline level — which is increasingly where SBOM guidance points — CycloneDX may be the path of least resistance.

SPDX vs CycloneDX: A Practical Comparison

The table below compares SPDX and CycloneDX across the dimensions that matter most for federal SBOM program design. Neither format dominates every category. The right read of this table is not “which format wins” but “which format fits the workflows my organization actually needs to support.”

Where the Formats Converge

Both formats support package URL (PURL) identifiers, which are the practical mechanism for linking component records to vulnerability databases and package registries. Both support CPE identifiers as well, though PURL has become the more operationally useful identifier for most modern tooling. Both formats support the core dependency graph relationships that NTIA minimum elements require — specifically, the ability to express what depends on what within a software package.

Both formats also have active converter tooling — meaning organizations can transform SPDX documents into CycloneDX and vice versa with varying degrees of fidelity loss. Conversion is not lossless. License expression detail that exists in SPDX may not translate cleanly into CycloneDX. Vulnerability metadata embedded in CycloneDX does not have a natural destination in SPDX. But the core component inventory data — names, versions, identifiers, relationships — generally survives conversion well enough to be operationally useful. For programs trying to build unified ingestion pipelines across mixed-format SBOM deliverables, converter tooling is a practical necessity rather than an edge case capability.

Where the Formats Diverge Under Operational Pressure

The divergence becomes most apparent when you push into the workflows beyond basic inventory. If a program office needs to conduct a license audit across all software components before a product ships — verifying that no GPL-licensed code is embedded in a proprietary system without authorization — SPDX’s license expression language is materially better suited to that workflow. The SPDX license list, the expression syntax, and the tooling built around it are purpose-built for that kind of legal analysis.

On the other hand, if a security operations team needs to ingest SBOM data into a vulnerability management platform and correlate it against CVE feeds, CycloneDX’s native vulnerability support and integration with security tooling ecosystems is a practical advantage. The same is true for programs dealing with embedded systems or firmware — CycloneDX’s hardware component model gives those programs a way to document the full stack in a single format rather than trying to force hardware components into a software-oriented schema.

Federal Context: NTIA, EO 14028, and Format Guidance

Executive Order 14028, signed in May 2021, directed NIST, NTIA, and other federal bodies to develop guidance around software supply chain security. NTIA’s response — the minimum elements report published that same year — established what an SBOM must contain to be considered minimally sufficient for federal use. The seven minimum elements are: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp.

NTIA explicitly acknowledged both SPDX and CycloneDX as formats capable of carrying those minimum elements, alongside SWID tags. The guidance did not mandate one format. It noted that the field was still maturing and that format standardization would likely evolve through market adoption and tooling maturity rather than top-down mandate. That assessment was accurate, and the federal market has responded largely as predicted — both formats are present, tooling supports both, and programs are left to make their own decisions.

NIST’s Secure Software Development Framework (SSDF), SP 800-218, and related guidance documents reference SBOM as a practice without prescribing format. CISA has published SBOM-related resources that reference both formats and has generally taken a format-neutral stance in its operational guidance. Some agency-specific guidance documents have begun specifying preferred formats in contract deliverable requirements, but those specifications are not yet consistent across the federal space.

The practical implication for federal programs is that format selection remains a program-level decision, which means it also remains a program-level risk. If your program accepts SBOM deliverables without specifying format, you will receive a mix. If you specify a format in contract language without thinking through your ingestion capability, you may specify one format and build tooling for another. Neither outcome serves the mission of actually using SBOM data to manage software supply chain risk.

Matching Format to Use Case

The most useful way to think about format selection is to start from what you actually need to do with the SBOM data and work backward to format requirements. The following framework is designed to help programs make that determination in a structured way rather than defaulting to whatever a vendor produces.

Common Mistakes

Federal programs making SBOM format decisions for the first time tend to make a predictable set of mistakes. Most of them stem from treating SBOM as a compliance artifact — something to check off — rather than as operational data that needs to flow into real workflows. The format errors are downstream of that foundational mistake, but they compound it.

Specifying format in contracts without validating ingestion capability. A program office writes contract language requiring SPDX 2.3 deliverables. The contractor produces SPDX 2.3 documents. The documents arrive and sit in a SharePoint folder because the receiving organization has no tooling that ingests SPDX. The SBOM requirement has been satisfied on paper and accomplished nothing operationally. This is more common than it should be. Contract language and technical capability need to be developed together.

Accepting minimum element SBOMs without checking field population. Both SPDX and CycloneDX allow documents to be structurally valid while being operationally empty. A document can have the right fields defined and still have most of them blank, unknown, or populated with placeholder text. Receiving a structurally valid SBOM document and a usefully populated one are different things. Programs need to define quality criteria for SBOM deliverables, not just format requirements.

Treating conversion as equivalent to native generation. Converting a CycloneDX document to SPDX for a downstream workflow that requires SPDX is a practical workaround, but the converted document will have less fidelity than one generated natively in SPDX. License expression detail is particularly likely to degrade. Understand what fidelity you are willing to accept before relying on conversion as your primary strategy for format compatibility.

Assuming the vendor-generated SBOM is complete. Software composition analysis tools that generate SBOMs do not always capture transitive dependencies — the dependencies of dependencies. A CycloneDX document generated by a pipeline SCA tool may accurately represent direct dependencies while missing nested ones. For security use cases where transitive dependency vulnerabilities are operationally relevant — and they frequently are — shallow SBOMs give false confidence. Validate SBOM depth as part of your acceptance criteria.

Conflating format maturity with program maturity. Receiving a well-formed CycloneDX 1.6 document does not mean your organization has a mature SBOM program. Format compliance is the easy part. The hard part is building the workflows, staffing the capability, maintaining the tooling, and making decisions based on what the SBOM data reveals. Programs that focus on format compliance at the expense of workflow development are building a paperwork process, not a risk management capability.

Ignoring SBOM timestamp and freshness. An SBOM that accurately represented a software system six months ago may not accurately represent it today. Dependencies change, components are updated, new packages are added. SBOM data has a shelf life. Programs should define how frequently SBOMs must be regenerated and how that requirement will be enforced through contract language or operational process. Stale SBOMs in vulnerability management workflows generate false confidence at exactly the wrong moment.

Recommended Federal Approach

The recommended approach for federal programs is not to pick a format and enforce it universally but to build a format-aware SBOM program that can handle both SPDX and CycloneDX in a way that serves actual operational requirements. That means making deliberate decisions in four areas: format specification, quality criteria, ingestion infrastructure, and workflow integration.

Define format requirements by use case, not by convenience. If your program has a legal requirement to audit open source license obligations, specify SPDX in contract deliverables for that use case and verify that license fields are populated. If your program’s primary SBOM use case is vulnerability management, specify CycloneDX and integrate that output with your vulnerability management platform. If you have both use cases, consider requiring both formats or accepting conversion with defined fidelity standards.

Build quality criteria into contract language. Beyond format, specify what “complete” means: minimum percentage of components with PURL identifiers populated, transitive dependency depth required, freshness window for SBOM regeneration, and verification that the SBOM author field accurately identifies who generated the document. NTIA minimum elements are a floor, not a ceiling. Programs with real operational requirements should define quality standards above that floor.

Invest in ingestion infrastructure before specifying format at scale. The most expensive mistake is building a format requirement into dozens of contracts and then discovering your organization cannot process the deliverables. Stand up an SBOM ingestion and analysis capability — even a minimal one — before expanding format requirements across your contract portfolio. Understand what your tooling actually supports, where its gaps are, and what manual process fills those gaps, before making promises about what you will do with the data.

Plan for both formats in your ingestion pipeline from the start. Even if your program specifies CycloneDX in new contracts, your legacy inventory will include SPDX documents, SWID tags, and ad hoc component inventories that predate formal SBOM requirements. Your ingestion pipeline needs to handle that reality. Converter tooling, normalization logic, and a common internal data schema that abstracts away format differences will make your program more durable as standards evolve.

Align with CISA and NIST guidance as it evolves. The federal SBOM landscape is still maturing. CISA has published operational guidance documents, tooling surveys, and community draft materials that reflect where practice is heading. NIST SP 800-161 on supply chain risk management and the supporting guidance around EO 14028 implementation are continuing to develop. A program that anchors its format decisions to guidance documents from 2021 without tracking updates will find itself out of step with both federal expectations and vendor tooling capabilities within a few years. Build a review cadence for your SBOM program standards, not just a one-time specification.

Ultimately, both SPDX and CycloneDX are mature, well-supported, and capable of satisfying federal SBOM requirements. The organizations that get the most value from their SBOM programs are not the ones that made the “right” format choice. They are the ones that built workflows around the data, invested in tooling that could process it, and made the format decision deliberately based on what those workflows actually need. That discipline — not format selection — is what separates programs that use SBOM data to manage real risk from programs that use it to satisfy a contract line item. For support building that kind of capability, explore the solutions Anchor Defense provides to federal programs working through exactly these challenges.