SBOMs in Practice: SPDX vs CycloneDX and What Actually Breaks

TL;DR — Which SBOM format should you use? SPDX and CycloneDX are the two standards that matter: SPDX (Linux Foundation, ISO/IEC 5962) grew out of license compliance; CycloneDX (OWASP-origin, standardized as Ecma-424) grew out of vulnerability management and is now the security default. The format choice is the easy part — what actually breaks adoption is generating complete transitive inventories, keeping them matched to what runs in production, and turning matching plus VEX into an alerting pipeline instead of a spreadsheet. With EU Cyber Resilience Act reporting obligations live since 11 September 2026, SBOM discipline is becoming a legal requirement, not a best practice.

Every security team has been told to “produce SBOMs” since the 2021 U.S. Executive Order 14028 made software transparency a procurement requirement. Four years on, the tooling is mature, both major formats are formally standardized, and the failure modes have moved from whether you can generate a bill of materials to whether it matches reality and whether anyone acts on it. This post is the practitioner’s map: the two formats, the generation reality, and the places adoption actually breaks.

We touched SBOMs in Part 7 of the EFB series as control 15 of a 20-control security program (“answer ‘which builds run?’ in under an hour”). This is the expanded, cross-industry version of that control.

What an SBOM Actually Is

A Software Bill of Materials is a machine-readable inventory of the components in a software artifact — libraries, packages, containers, sometimes the full transitive dependency tree — with names, versions, and ideally licenses and checksums. The U.S. NTIA “minimum elements” definition (2021) set the floor: supplier, component name, version, unique identifiers, dependency relationships, and the SBOM’s own author and timestamp.

The point is not the document. The point is the query it enables: when the next supply-chain disclosure lands, “are we running the affected build?” becomes a database lookup instead of an archaeology project across Slack, CI logs, and container registries.

SPDX vs CycloneDX: The Honest Comparison

In practice most organizations end up CycloneDX for internal security pipelines, SPDX where contracts or regulators ask for the ISO number — and converting between them with tooling when required. The formats are converging on identifiers (both support package URLs and SWHID); pick one, generate consistently, and stop relitigating.

Generation: The Part Everyone Underestimates

There are three ways to produce an SBOM, with very different fidelity:

• Build-time instrumentation — the build system emits the manifest as it resolves dependencies (CycloneDX plugins for Maven/Gradle/npm, go mod awareness, cargo auditable builds). Highest fidelity for the dependency tree as the compiler saw it.
• Artifact and image scanning — tools like Syft parse lockfiles, binaries, and container layers after the fact. Works everywhere, but can miss statically-linked or vendored code and guesses on stripped binaries.
• Source-only analysis — reading the repo’s manifests. Fastest, and the most wrong at runtime, because it sees declared dependencies, not resolved-and-deployed ones.

The gold standard is build-time emission attached to the artifact (OCI image annotation or a signed sidecar), with an image scan as a cross-check. The two disagreeing is itself a signal worth alerting on.

What Actually Breaks in Adoption

The failure modes are consistent across organizations, and none of them are “we picked the wrong format”:

1. Identity chaos. The same library is github.com/foo/bar, bar.js, a Debian source package, and three Maven coordinates. Without disciplined package-URL (purl) normalization, your “are we affected?” query returns false negatives — which is worse than no SBOM, because it confidently lies.
2. Transitive depth variance. Generator A emits the full dependency tree, generator B the direct dependencies only. Teams merge both and either double-count or under-count. Standardize one generator per artifact type.
3. Runtime drift. The SBOM describes the build; production runs the container with hotfix layers, sidecar mutations, and base-image refreshes. SBOMs must be regenerated per build and stored keyed to the digest — a per-commit artifact, not a per-project document.
4. The matching problem. Turning “component@version” into “we are affected by CVE-2026-XXXX” is where pipelines die: version schemes differ per ecosystem (semver, CalVer, epoch-locked distro versions), and naive matching floods teams with false positives.
5. VEX immaturity. Vulnerability Exploitability eXchange statements (“not affected — the vulnerable code path is unreachable”) are the intended antidote to alert fatigue, and they work — but only if vendors ship them and your pipeline consumes them. Most still don’t, so triage stays manual.
6. Ownership. The SBOM exists, the alert fires at 02:00, and no one knows whose service it is. Without service metadata in the BOM (CycloneDX supports it), the pipeline produces noise, not action.

Who Consumes the SBOM — and What Each Needs

A BOM with one reader is a compliance artifact; the useful ones have four audiences with different questions:

• AppSec / incident response — “which builds contain the affected component, and who owns them?” Needs purl-precise matching, digests, and service metadata. Prefers CycloneDX.
• Legal / OSS governance — “what licenses are we redistributing, and do any conflict?” Needs SPDX’s license expressions and copyright fields, conformance, and a review workflow.
• Procurement / vendors — “prove what’s in the product you sold us.” Needs a deliverable with a standard’s name on it, per the EO 14028 / OMB line of requirements.
• Regulators (arriving now) — the EU CRA’s reporting clock means manufacturers must reconstruct component exposure quickly enough to meet 24-hour early-warning duties for actively exploited vulnerabilities. That is an SBOM-plus-pipeline capability by another name.

One generation step, four consumers, different views — which is why the storage answer is “a queryable index keyed by artifact digest”, not “a folder of JSON files.”

Where the Formats Are Heading

Both standards are alive and moving. CycloneDX v1.7 (2025, second edition of Ecma-424) continues to deepen its security surface — cryptography and proof-of-provenance fields, and machine-learning BOMs for the “which model, trained on what data” question that AI-heavy shops already face. SPDX 3.0 (2024) reworked the specification into a modular profile model — software, licensing, security, and AI/dataset profiles — shedding some legacy modeling constraints of the 2.x line. For adopters the practical read: generate current-spec documents, consume defensively (parse what you recognize), and expect AI-component inventory to become the next battleground after libraries, containers, and firmware.

The Regulatory Clock Is Running

The U.S. track made SBOMs procurement hygiene: EO 14028 (2021), OMB guidance M-22-18 and M-23-16 pushed agencies and their vendors toward attestations and SBOM delivery. The sharper deadline is European: the Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024, its vulnerability- and incident-reporting obligations apply from 11 September 2026 — with 24-hour early warnings for actively exploited vulnerabilities — and its main obligations apply from December 2027. Manufacturers of software-bearing products need to know their components, their provenance, and their exposure with a speed that presupposes exactly the pipeline above.

The window between “voluntary best practice” and “legally required in an incident” has closed. Build the muscle now, on your own incidents and audits, rather than during your first regulator-notifiable event.

A Pragmatic Reference Pipeline

Key Takeaways

• Format is the easy decision: CycloneDX (Ecma-424) for security pipelines, SPDX (ISO/IEC 5962) where license/compliance or the ISO number is required; convert between them when needed.
• Fidelity hierarchy: build-time emission > artifact/image scanning > source analysis. Cross-check the top two and alert on disagreement.
• What breaks is identity normalization, transitive-depth consistency, runtime drift, advisory matching, and VEX consumption — not XML versus JSON.
• Treat SBOMs as per-build artifacts keyed to digests, never as per-project documents.
• The EU Cyber Resilience Act’s reporting obligations have applied since 11 September 2026; component transparency is now an incident-response capability with legal deadlines behind it.

FAQ

Do I need SPDX or CycloneDX?
If your consumers are security tooling: CycloneDX. If they are lawyers, procurement, or regulators asking for an ISO standard: SPDX. Running both from one generator is cheap; the expensive part is keeping either one true.

What is VEX?
Vulnerability Exploitability eXchange — a machine-readable statement of whether a product is actually affected by a given vulnerability in a given version. It is the intended antidote to SBOM-driven alert fatigue; adoption by vendors is still uneven.

Can scanners generate complete SBOMs from binaries?
Partially. Lockfiles and package-manager metadata parse cleanly; statically-linked, vendored, or stripped code is where scanning guesses. Highest fidelity comes from emitting the SBOM during the build.

Is an SBOM required by law?
Increasingly, yes: U.S. federal software acquisition guidance pushes SBOM delivery for vendors, and the EU Cyber Resilience Act (fully applicable December 2027) requires manufacturers to know and manage the components of products with digital elements.

How often should SBOMs be generated?
Every build. A stale SBOM is actively dangerous — it answers the incident-response question with yesterday’s truth.

Where should SBOMs be stored?
Attached to the artifact they describe (OCI registry as image annotations or companion artifacts), with a queryable index on top — not in a git repo of flat files.

References

1. CycloneDX — the bill of materials standard (Ecma-424); v1.6 ratified as an Ecma International standard
2. Ecma International — ECMA-424
3. SPDX — Software Package Data Exchange (ISO/IEC 5962:2021)
4. CISA — Software Bill of Materials resources; NTIA, Minimum Elements for an SBOM (2021)
5. European Commission — Cyber Resilience Act (Regulation (EU) 2024/2847): reporting obligations from 11 September 2026, main obligations from 11 December 2027
6. Executive Order 14028 (2021) and OMB memoranda M-22-18 / M-23-16 — U.S. federal software supply-chain requirements
7. hmmnm.com — Securing the EFB: DO-326A and Defense-in-Depth (SBOM as operator control 15); The Pipeline Is the Attack: AST02 Skill Supply Chain Compromise

Current as of September 2026 · standards verified against published sources.

Educational reference only — verify obligations against the current regulatory text for your jurisdiction.

Author: hmmnm.com editorial team · hmmnm.com

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy