Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory that lists every software component, library, framework, and dependency included in a product — including version numbers, suppliers, and licensing information. It functions as a “nutrition label” for software, enabling organizations to identify and remediate known vulnerabilities across their entire software supply chain.

Key Facts

Why Does SBOM Matter for Hardware?

Embedded hardware products — IoT devices, industrial controllers, FPGA-based systems — ship with firmware stacks that include dozens to hundreds of software components: RTOS kernels, networking stacks, cryptographic libraries, bootloaders, and drivers. When a vulnerability is discovered in any of these components (e.g., a critical OpenSSL CVE), the SBOM enables:

1. Immediate impact assessment — Determine within hours which products and firmware versions are affected.
2. Targeted patching — Issue OTA updates only to affected devices rather than blanket reflashing entire fleets.
3. Regulatory evidence — Provide auditors and market surveillance authorities with documented proof of vulnerability management processes.
4. Customer transparency — Enable enterprise buyers to evaluate supply chain risk before procurement.

Without an SBOM, a manufacturer discovering that a library used three firmware releases ago has a critical vulnerability faces weeks of forensic analysis to determine exposure — time that regulators and attackers do not grant.

SBOM Formats

Both formats support JSON and XML serialization. For embedded firmware, CycloneDX is often preferred due to its native support for hardware component descriptors and Vulnerability Exploitability eXchange (VEX) statements.

SBOM in the Embedded Firmware Lifecycle

1. Build phase
   ├── Toolchain auto-generates SBOM from build manifest
   ├── Captures: component name, version, hash, license, supplier
   └── Tools: Yocto (create-spdx), Zephyr (west spdx), syft, trivy

2. Release phase
   ├── SBOM attached to firmware release artifact
   ├── Signed alongside firmware binary
   └── Stored in version-controlled artifact repository

3. Monitoring phase
   ├── Continuous CVE scanning against SBOM components
   ├── Automated alerts when new vulnerabilities match SBOM entries
   └── Tools: Dependency-Track, Grype, OSV.dev

4. Incident response
   ├── SBOM lookup identifies all affected products/versions
   ├── VEX statement published: affected, not affected, or under investigation
   └── OTA update dispatched to affected device fleet

CRA Requirements for SBOM

Under the EU Cyber Resilience Act, manufacturers must:

• Generate a machine-readable SBOM for every product with digital elements.
• Maintain the SBOM throughout the product’s supported lifetime (minimum 5 years).
• Update the SBOM with each firmware release.
• Monitor listed components for newly discovered vulnerabilities.
• Report actively exploited vulnerabilities to ENISA within 24 hours.
• Provide the SBOM to market surveillance authorities upon request.

Common Mistakes

Related Terms

• CRA — The EU regulation that mandates SBOM for connected products.
• Secure Boot — Firmware integrity verification, complementary to SBOM supply chain tracking.
• IoT — Connected devices whose firmware stacks benefit most from SBOM transparency.