Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a structured, machine-readable list of every software component that contributes to a product - analogous to an ingredients list on food packaging. It records each component's name, version, supplier, licence, cryptographic hash, and relationship to other components. The three dominant SBOM formats are CycloneDX (OASIS standard, widely used in Europe), SPDX (Linux Foundation / ISO/IEC 5962), and SWID Tags (ISO/IEC 19770-2). CycloneDX v1.5+ additionally supports hardware components and vulnerability data (VEX), making it particularly well-suited for embedded and IoT product manufacturers subject to the CRA.

Annex I Part II, §1 of the CRA requires manufacturers to identify and document components in their products, including third-party and open-source software. Article 13(3) requires this information to be maintained as part of technical documentation throughout the product support period. Practically, this means:

• An SBOM must be generated at build time and updated with each release.
• The SBOM covers at the very least the top-level dependencies, which is the floor Annex I Part II(1) sets. Deeper transitive coverage is permitted and answers a vulnerability question faster.
• It must be available to market surveillance authorities on request.
• Manufacturers must monitor SBOM components against vulnerability feeds (CVE/NVD) to detect newly disclosed vulnerabilities affecting their products.

Public customer-facing SBOM disclosure is not explicitly required, but is increasingly expected by enterprise buyers.

For most manufacturers, SBOM generation is integrated into the build pipeline:

1. Source-level scanning - tools analyse package manifests (npm, Maven, pip, Cargo, Conan) to enumerate declared dependencies.
2. Binary analysis - for firmware and compiled artefacts, binary SCA tools identify components not visible from source alone.
3. SBOM signing - the generated SBOM document is signed to ensure authenticity and detect tampering.
4. Continuous monitoring - the SBOM is submitted to a vulnerability intelligence feed; new CVEs matching component versions trigger triage workflows.

Key tools in the CycloneDX ecosystem include Syft, cdxgen, and Dependency-Track (monitoring). SPDX tooling includes SPDX Tools and FOSSology.

Manufacturers building SBOM programmes frequently encounter:

• Incomplete dependency graphs - capturing only direct dependencies misses transitive vulnerabilities, which account for the majority of supply chain risks.
• Static SBOMs - an SBOM generated once at initial release becomes inaccurate within weeks as dependencies change; automated regeneration per release is required.
• No monitoring - an SBOM that is generated but never checked against vulnerability feeds provides no operational value.
• Ignoring firmware components - OS kernels, bootloaders, and proprietary libraries embedded in firmware must be included; source-only SCA tools miss these.
• Wrong format for the audience - SPDX is preferred for licence compliance; CycloneDX is preferred for security operations and CRA conformity assessment.