SBOM for hardware manufacturers — CycloneDX vs SPDX practical guide

A Software Bill of Materials (SBOM) is a machine-readable list of every software component contained in a product. Under the Cyber Resilience Act Annex I Part II item (1), maintaining and providing an SBOM becomes a mandatory obligation for every product with digital elements placed on the EU market from 11 December 2027.

This guide walks through what an SBOM is, the two competing canonical formats (CycloneDX and SPDX) and when to choose which, the tooling for generating SBOMs from hardware build pipelines, how to maintain them through the product lifecycle, who to share them with, and the relationship between SBOM and the VEX (Vulnerability Exploitability eXchange) format.

What an SBOM is — and is not

An SBOM lists the software components in a product. For each component it records:

• Name — the canonical component name (e.g. openssl, mbedtls, freertos)
• Version — the specific version included (e.g. 3.0.13, 2.28.4)
• Supplier — the upstream maintainer or vendor (e.g. The OpenSSL Project, Trustworthy Systems / Linaro)
• Unique identifier — a Package URL (pkg:generic/openssl@3.0.13) or SPDX identifier or CPE
• Hash — cryptographic hash (SHA-256) of the binary or source artefact
• License — SPDX license identifier (Apache-2.0, BSD-3-Clause, GPL-3.0-or-later)
• Source URL or download location — where the component was sourced from
• Known vulnerabilities — optionally, CVE identifiers known at release time

What an SBOM is not:

• A vulnerability scan result — the SBOM is the input to vulnerability monitoring, not the output
• A license compliance report — the SBOM contains license metadata but the compliance assessment is a separate activity
• A code coverage or quality metric — the SBOM describes components, not their internal quality
• An exhaustive inventory of every line of code — granularity is component-level, not file-level

Why the CRA mandates SBOMs

The legal basis is Annex I Part II item (1):

"Identify and document vulnerabilities and components contained in the product with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product."

The SBOM is the machine-readable foundation that all other CRA vulnerability handling requirements depend on:

• Item (2) — addressing vulnerabilities without undue delay requires knowing which components are affected
• Item (3) — regular security testing requires knowing what to test
• Item (4) — publicly disclosing fixed vulnerabilities requires identifying affected versions
• Item (7) — securely distributing updates requires tracking component-level state

Without an SBOM, the rest of Part II is unverifiable.

Beyond CRA, SBOMs are mandated or recommended under:

• US Executive Order 14028 (2021) — federal procurement
• NIST SP 800-218 — Secure Software Development Framework
• NIS2 Directive — Article 21 risk management for essential and important entities
• ENISA Good Practices for Supply Chain Cybersecurity
• DORA — Digital Operational Resilience Act for financial entities (from January 2025)

CycloneDX vs SPDX — practical comparison

Both formats satisfy CRA Annex VII and both are accepted by market surveillance authorities. Choose based on the use case:

For most hardware manufacturers building connected products in 2026 the practical choice is CycloneDX:

• Security-focused metadata aligned with CRA Annex I Part II
• Native VEX integration for downstream vulnerability assertions
• Broader tooling coverage in embedded build systems
• Simpler JSON structure that integrates easily into CI pipelines

Manufacturers selling into US federal procurement (where SPDX is the historical default), or into large enterprise customers with mature SPDX workflows, frequently provide both formats — generating SPDX from the CycloneDX source via a conversion tool.

CycloneDX SBOM — a minimal example

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-06-20T10:00:00Z",
    "tools": [{ "vendor": "Anchore", "name": "syft", "version": "1.10.0" }],
    "component": {
      "type": "device",
      "name": "ConnectedSensor-X1",
      "version": "1.4.2",
      "supplier": { "name": "Inovasense s.r.o." }
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.13",
      "purl": "pkg:generic/openssl@3.0.13",
      "hashes": [{ "alg": "SHA-256", "content": "abc123…" }],
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    }
  ]
}

The structure is intentionally compact. Tooling reads it; humans rarely read it directly.

Tooling for generating SBOMs

In 2026 the practical tooling landscape for hardware manufacturers:

For embedded firmware specifically:

• Yocto/OpenEmbedded has native SPDX generation since the Kirkstone release
• Buildroot has SBOM generation via make legal-info
• ESP-IDF (Espressif) has CycloneDX plugin support since v5.2
• Zephyr RTOS has SPDX generation as part of the West build tool

For closed-source firmware blobs (radio chipset drivers, baseband modem firmware), the supplier should provide a component-level SBOM that the manufacturer integrates into the product-level SBOM.

VEX — telling downstream consumers what's actually exploitable

The SBOM lists components and their known vulnerabilities. The downstream consumer (or the manufacturer themselves) often hits a wall of false positives — a CVE in openssl 3.0.13 may exist in the library but be unreachable in the product because the affected code path is never invoked.

VEX — Vulnerability Exploitability eXchange — addresses this. A VEX statement is a machine-readable assertion of the form:

• "CVE-2024-12345 affects openssl 3.0.13 listed in our SBOM"
• "In our product context this CVE is not_affected" (or affected, fixed, under_investigation)
• "Justification: the affected code path is unreachable because we do not enable TLS 1.0"

Two VEX formats coexist:

• CycloneDX VEX — embedded in the SBOM as vulnerabilities block
• CSAF VEX — standalone JSON, OASIS standard, used by US CISA and many vendors

For most hardware manufacturers, embedding VEX in CycloneDX is the cleaner approach — one document carries both the inventory and the per-CVE context. For multi-vendor coordinated disclosure where multiple vendors must converge on a single VEX statement, CSAF VEX is the more interoperable choice.

SBOM maintenance lifecycle

An SBOM is not a one-time deliverable. The lifecycle per product release:

1. Generate — at the end of the build pipeline, automatically
2. Validate — against the CycloneDX or SPDX schema
3. Sign — cryptographically, so consumers can verify provenance
4. Store — alongside the firmware binary and the Technical File, version-controlled
5. Distribute — to market surveillance authorities on request, to enterprise customers via secured portal, to security researchers via CVD flow
6. Monitor — against vulnerability feeds (NVD, GitHub Security Advisories, vendor advisories) continuously
7. Update — issue a new SBOM with each release that changes any component; maintain historic versions for the retention period

Cenitia automates step 6 for SBOMs uploaded into the system — vulnerability feeds are checked daily against the SBOMs in your organisation and affected products are flagged with VEX-ready triage guidance.

Common SBOM mistakes

From the Inovasense practice and the Cenitia review pipeline:

• No SBOM at all. The default state for many embedded products in 2025-2026. From December 2027 this is non-conformity with CRA Annex I Part II.
• One SBOM generated at first release, never updated. Annex I Part II requires per-release maintenance.
• SBOM with only the high-level applications, missing OS and library layers. "Top-level dependencies" includes the kernel, libc, the RTOS, the radio stack — not just the manufacturer-authored application.
• Missing closed-source firmware blobs. Wi-Fi chipset firmware, baseband modem firmware, GPU firmware blobs are software components and must be listed.
• Unsigned SBOM. Downstream consumers cannot verify the SBOM came from the manufacturer unaltered.
• No VEX statements. Vulnerability monitoring on the SBOM surfaces dozens of CVEs that are not actually exploitable in product context. Without VEX, downstream consumers are unable to triage.
• No retention plan. SBOMs must be retained for ten years under CRA Annex VII alongside the Technical File. Historic SBOMs enable retrospective vulnerability monitoring on the installed base.
• SBOM stored on a developer's laptop instead of in version control. Loss of historic SBOMs is loss of historic compliance evidence.

How Cenitia helps with SBOMs

Cenitia ingests SBOMs in CycloneDX or SPDX format, integrates them into the per-product Technical File, monitors them against NVD and vendor advisory feeds, and surfaces affected components when new CVEs are published. The Cenitia regulation watcher tracks CRA Annex I Part II amendments for changes to the SBOM requirements; when CRA is amended, affected SBOM workflows are flagged.

For products that need expert SBOM tooling integration into existing build pipelines, or specialist SBOM consulting for high-stakes products, our parent company Inovasense provides engineering services.

Frequently asked questions

What is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable list of all software components contained in a product — including operating system, libraries, runtimes, drivers, firmware blobs, and build-time toolchain. Each component is listed with its name, version, supplier, license, and unique identifiers. SBOMs enable vulnerability monitoring, license compliance, and regulatory disclosure under the Cyber Resilience Act and similar frameworks.

Is an SBOM mandatory under the Cyber Resilience Act?

Yes. CRA Annex I Part II item (1) requires manufacturers to identify and document vulnerabilities and components contained in the product. The implementing form is a machine-readable SBOM in 'a commonly used format' — in practice CycloneDX or SPDX. The SBOM must cover at least top-level dependencies per Annex I Part II, must be maintained throughout the support period, and must be made available to market surveillance authorities on request. From 11 December 2027 this is mandatory for every product with digital elements placed on the EU market.

CycloneDX or SPDX — which one should I use?

Both satisfy CRA Annex VII and both are accepted by market surveillance authorities. CycloneDX is typically chosen for security-first use cases — it has tighter metadata for vulnerabilities (VEX integration), better tooling coverage in 2026 (Syft, Trivy, FOSSA, Anchore, native build-system plugins), and a more compact JSON format. SPDX is typically chosen for license-first use cases — it has stronger license expression syntax, more mature integration with enterprise procurement workflows, and is the ISO/IEC 5962 standardised format. For hardware manufacturers building in-house tooling, CycloneDX is usually the simpler choice; for manufacturers selling into large enterprise procurement, providing SPDX alongside is common.

Do I need SBOMs for closed-source firmware components?

Yes. The SBOM lists components regardless of source availability. A closed-source third-party firmware blob (a Wi-Fi chipset driver, a baseband modem firmware) is listed with its supplier, version, and known vulnerabilities even when source code is unavailable. The supplier of the closed-source component is responsible for providing its own component-level SBOM and vulnerability information.

How granular must the SBOM be?

CRA Annex I Part II requires 'at the very least the top-level dependencies'. In practice this means every component directly included in the product — every library statically linked, every runtime dynamically linked, every package installed in the firmware image, every utility shipped in the rootfs. Going one level deeper (transitive dependencies) is recommended for vulnerability monitoring quality but not strictly mandated. For container-based products and Linux-based embedded systems, full transitive SBOMs are practical and standard.

How often does an SBOM need to be updated?

A new SBOM with every product release that changes any software component. Maintaining historic SBOMs alongside historic firmware versions enables vulnerability monitoring on the installed base — when a new CVE is published, the manufacturer can identify which firmware versions are affected by checking each historic SBOM. Retention is the same as the Technical File: ten years from last unit placed on market under CRA Annex VII.

What is VEX and how does it relate to SBOM?

VEX — Vulnerability Exploitability eXchange — is a companion machine-readable format that asserts whether specific CVEs affecting components in an SBOM are actually exploitable in the product context. An SBOM lists components and their known vulnerabilities; the VEX statement says 'CVE-2024-12345 affects component X version Y; in our product the affected code path is not reachable so this vulnerability is not exploitable here'. Both CycloneDX and CSAF VEX formats are supported by tooling. VEX significantly reduces false-positive vulnerability noise for both the manufacturer and downstream consumers.

Who should I share the SBOM with?

Market surveillance authorities on request — mandatory under CRA. ENISA and member-state CSIRTs during incident response coordination under CRA Article 14. Enterprise customers and procurement frameworks (NIST 800-218 in US, NIS2 in EU) frequently require SBOM disclosure at the contracting stage. Security researchers participating in your coordinated vulnerability disclosure programme need SBOM access to verify reported issues. Public SBOM publication is becoming common practice but is not mandatory under CRA.

Related from the Library

• CRA Annex I explained — the Annex I Part II item (1) requirement the SBOM satisfies
• Technical File 101 — where the SBOM lives in the documentation stack
• CRA timeline and reporting obligations — the September 2026 reporting that depends on SBOM-driven vulnerability tracking

Further reading

• CycloneDX specification — current version 1.5 / 1.6 draft
• SPDX specification — ISO/IEC 5962:2021
• CISA SBOM resources
• ENISA Good Practices for Supply Chain Cybersecurity
• NTIA Minimum Elements for an SBOM — US baseline that informed CRA
• OASIS CSAF VEX
• Syft documentation — open-source SBOM generation
• Trivy documentation — SBOM + vulnerability scanning

Last reviewed: 20 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.