SBOM Formats Explained: SPDX vs CycloneDX
Frontend Development
September 15, 2026•5 min read
I hope you enjoy reading this post. If you want us to do your frontend development or design, click here.
Author: Pavlo Tyshchenko | COO at The Frontend Company
Two SBOM formats dominate in practice: SPDX, the Linux Foundation standard with ISO status and a license-compliance pedigree, and CycloneDX, the OWASP standard built for security use cases. The EU Cyber Resilience Act mandates neither by name — it requires an SBOM "in a commonly used and machine-readable format" covering at least your product's top-level dependencies. So the honest answer up front: either format satisfies the CRA today. Pick by what your tooling and your customers consume — and set CI up to export both, because it's usually one extra flag.
What is an SBOM, and why does it suddenly matter?
A software bill of materials is a machine-readable inventory of everything your software is built from: components, versions, suppliers, licenses, and how they depend on each other. The reason it stopped being optional is arithmetic: in Black Duck's 2026 OSSRA analysis of 947 commercial codebases, 98% contained open source, the average application carried 1,180 open-source components, and 87% had at least one known vulnerability. When a Log4Shell-class vulnerability drops, the SBOM is the difference between answering "are we affected?" in minutes and in weeks.
Two regulatory pushes turned good practice into requirement. In the US, Executive Order 14028 (2021) made SBOMs part of federal software procurement and produced the NTIA's minimum-elements definition — replaced in July 2026 by CISA's expanded 2026 Minimum Elements. In the EU, the Cyber Resilience Act — Regulation (EU) 2024/2847, in force since December 10, 2024 — makes an SBOM part of the technical documentation for products with digital elements. Its reporting obligations for actively exploited vulnerabilities and severe incidents have applied since September 11, 2026, and the bulk of the obligations apply from December 11, 2027. If those dates are news, start with our Cyber Resilience Act guide.
The two SBOM standards that matter
SPDX and CycloneDX are the whole practical conversation. A third, SWID tags (ISO/IEC 19770-2), predates both and still appears in some enterprise asset-management contexts, but new pipelines don't start there. The two live standards came out of different problems — and it shows in their bones.
SPDX: the license-compliance veteran
SPDX (Software Package Data Exchange) grew out of the Linux Foundation's open-source license-compliance work, starting in 2010. It became an international standard as ISO/IEC 5962:2021, and SPDX 3.0 — a major restructuring around profiles for security, licensing, build, and AI — was released in April 2024. Two years on, the installed base is still mostly 2.3: most generators emit SPDX 2.3 by default and 3.x support is arriving tool by tool, so check what your consumers can actually parse before you flip the version switch.
Anatomy of an SPDX document: creation info (who made the SBOM, when, with which tool), packages and files with checksums, and typed relationships between elements — DESCRIBES, DEPENDS_ON, CONTAINS, and a few dozen more. Its license modeling is the deepest in the field: SPDX license identifiers (MIT, Apache-2.0, and hundreds more) are so standard they're used far beyond SBOMs. Serializations: tag-value, JSON, YAML, and RDF.
Where it shines: license and IP compliance, procurement contexts that ask for the ISO standard, and the US federal ecosystem. Where it's historically thinner: security-workflow metadata — improving in 3.0, but tooling is still catching up.
CycloneDX: the security-first challenger
CycloneDX is an OWASP flagship project, designed from the start for security use cases. Version 1.6 was ratified as Ecma-424 in June 2024, and the current release, CycloneDX 1.7 (October 2025), extended the spec to cryptographic assurance, intellectual-property visibility, and data provenance, and became the standard's second edition in December 2025.
Anatomy of a CycloneDX BOM: metadata about the subject, a components list identified by package URL (purl) with hashes and licenses, an explicit dependency graph, plus optional services, external references, and vulnerability data. Two design choices give it the edge in security pipelines: native VEX support (Vulnerability Exploitability eXchange — the machine-readable way to say "we ship this component, but the CVE doesn't affect us"), and the xBOM family — the same core spec extends to hardware (HBOM), SaaS dependencies (SaaSBOM), machine-learning models (ML-BOM), and cryptographic inventories (CBOM), which post-quantum migration planning is starting to demand. Serializations: JSON, XML, protobuf.
Where it shines: vulnerability management, DevSecOps toolchains, anything VEX-adjacent. Where it trails: license-compliance depth and the formal ISO badge — Ecma standardization narrowed that gap, but procurement checklists don't always know it.
SPDX vs CycloneDX: side by side
Dimension | SPDX | CycloneDX |
|---|---|---|
Steward | Linux Foundation | OWASP |
Standard status | ISO/IEC 5962:2021; SPDX 3.0 (2024) | Ecma-424: 1.6 (2024), 1.7 (2025) |
Primary lens | License and IP compliance | Security and vulnerability workflows |
Component identity | SPDX IDs; external refs (purl, CPE) | purl-first, plus CPE and SWID |
Dependency graph | Typed relationships | Explicit dependency graph |
VEX support | Via profiles and external efforts | Native |
Beyond software | Emerging in 3.0 profiles (AI, build) | xBOM family: HBOM, SaaSBOM, ML-BOM, CBOM |
Serializations | Tag-value, JSON, YAML, RDF | JSON, XML, protobuf |
What does the CRA actually want from your SBOM?
The regulation's Annex I (Part II) requires manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine-readable format that covers at the very least the product's top-level dependencies (Regulation (EU) 2024/2847, Annex I). Three practical clarifications:
- No named format. SPDX and CycloneDX both qualify as "commonly used and machine-readable." Article 13(24) lets the European Commission specify the SBOM's format and elements later through an implementing act — none has been adopted as of September 2026, and the Commission's July 2026 application guidance is non-binding.
- Not public by default. The SBOM is part of your technical documentation, available to market surveillance authorities on request — the CRA doesn't force you to publish it to end users.
- Top-level is the floor, not the goal. Answering "are we affected by this CVE in a transitive dependency" — which the reporting regime in force since September 2026 makes urgent — needs the full dependency tree. Generate the complete graph; it costs nothing extra.
Worth knowing: Germany's BSI TR-03183-2, the technical guideline many EU teams treat as the reference implementation of CRA-era SBOM expectations, accepts exactly these two formats — its current version 2.1.0 (August 2025) asks for CycloneDX 1.6 or later, or SPDX 3.0.1 or later, serialized as JSON or XML.
How do you generate each format?
Modern tooling makes the format choice cheap, because most tools emit both:
- syft (Anchore) — scans directories and container images; outputs SPDX and CycloneDX with a format flag.
- trivy (Aqua) — the same dual-format story, and it's often already in your pipeline for vulnerability scanning.
- cdxgen (OWASP) — CycloneDX-native generator with wide ecosystem coverage.
- npm sbom — built into npm since v10.2 (October 2023); emits SPDX or CycloneDX for a Node project via --sbom-format.
- GitHub — exports a repository's dependency graph as SPDX JSON from the UI or the REST API.
- Build-tool plugins — cyclonedx-maven-plugin, the Gradle CycloneDX plugin, and SPDX equivalents for JVM builds.
Converting between formats after the fact is possible — the OpenSSF's protobom project exists for exactly this, though it is still a sandbox-stage project short of a 1.0 release — but conversions are lossy where concepts don't map one-to-one. Emitting both natively in CI is the cleaner pattern.
Transform your UI for peak performance!
🔹
Unlock seamless, high-performance frontend solutions tailored to your business.
🔹
Get an interface that outshines competitors and delights your users.
What does an SBOM record actually look like?
For one dependency — say, a lodash package — the same facts land in differently named fields:
What's recorded | SPDX 2.3 (JSON) | CycloneDX 1.6 (JSON) |
|---|---|---|
Component name | name | name |
Version | versionInfo | version |
Unique identity | externalRefs with a purl entry | purl (first-class field) |
License | licenseConcluded / licenseDeclared | licenses |
Integrity | checksums | hashes |
Dependency link | relationships (DEPENDS_ON) | dependencies graph |
Same component, same facts, two dialects — which is why "which format" is a tooling-and-consumer question, not a data question.
Which SBOM format should you pick?
The decision rules we use:
- A customer or regulator named a format? Done — use that one.
- Security pipeline first (vulnerability management, VEX, DevSecOps)? CycloneDX — native VEX and the broadest security-tool support.
- License compliance, IP due diligence, ISO-minded procurement? SPDX — the deepest license model and the ISO standard the checklist asks about.
- CRA compliance specifically? Either works today. Wire CI to emit both and revisit if an implementing act names one.
SBOM generation is the easy 20% of CRA readiness — the harder 80% is secure-by-default configuration, update mechanics, and the vulnerability-handling process behind the reporting obligations that are now live. That's the work we do with product teams as CRA readiness and engineering; the full picture is in the Cyber Resilience Act guide.
Is your product CRA-ready for the deadlines?
We help product teams with CRA readiness and engineering: dependency hygiene, SBOM generation wired into CI, and the update and reporting mechanics behind it. Reporting obligations have applied since September 11, 2026, and full compliance is due December 11, 2027. Book a call to scope it.
FAQ
Pavlo Tyshchenko is COO at The Frontend Company, where he runs operations, delivery, and the internal systems the company runs on - AI workflows, knowledge infrastructure, and hiring. He writes about AI agents, process automation, and the engineering side of software compliance.
Follow the expert:
LEARN MORE
