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. For in-scope products, CRA Annex I Part II point 1 includes an SBOM obligation when the applicable main product duties apply. Check the Article 2 scope and Article 69 transition rather than applying every duty to every digital product or legacy unit.

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 are candidate machine-readable formats. Check the chosen schema version, dependency coverage, recipient requirements and tool interoperability. A format name alone does not prove conformity:

Choose the format your recipient and pinned toolchain can consume. Compare supported profiles, schema versions and required security/licence fields. If providing both, validate the conversion and any lost relationships or assertions. This article does not establish a universal government-procurement default or benchmark proving one format is best for all embedded products.

CycloneDX SBOM — a synthetic structural example

All names and versions below are fictional. This is a schema example, not scanner output, a real firmware inventory or evidence of CRA coverage.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "version": 1,
  "metadata": {
    "component": {
      "type": "device",
      "bom-ref": "demo-device",
      "name": "ExampleSensor",
      "version": "demo-1"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "example-library",
      "name": "example-library",
      "version": "demo-1",
      "purl": "pkg:generic/example-library@demo-1"
    }
  ],
  "dependencies": [
    {
      "ref": "demo-device",
      "dependsOn": [
        "example-library"
      ]
    },
    {
      "ref": "example-library",
      "dependsOn": []
    }
  ]
}

This compact example illustrates document structure only. A real release needs actual component identities, versions, dependencies and traceability to its firmware artifact.

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. Apply the documentation retention rule in CRA Article 13(13): at least ten years after placing on the market or the support period, whichever is longer. 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.

Using Cenitia for this work

Cenitia helps prepare evidence-linked working drafts within its supported regulatory catalogue. Confirm the product scope, actual applied standards and completed assessments, and review the result before issuance. Source-change alerts prompt a review; they do not certify conformity, automatically reissue a signed declaration or guarantee monitoring of every national rule and standard edition.

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