SBOM

What is an SBOM?

A software bill of materials (SBOM) is a formal, machine-readable inventory of the components that make up a piece of software: open-source libraries, vendor SDKs, operating system packages, the bootloader, the RTOS, the crypto library. For every component it records at least the name, version, supplier and a unique identifier, plus the dependency relationships between components, and metadata about who created the SBOM and when. The analogy is the parts list that comes with physical products; the purpose is the same: when a part turns out to be faulty, you can find every product that contains it.

Two formats dominate. SPDX, maintained under the Linux Foundation and standardised as ISO/IEC 5962, and CycloneDX, an OWASP project standardised by Ecma. Both are produced by common build tools and consumed by vulnerability scanners. A companion document type, VEX (Vulnerability Exploitability eXchange), records whether a known vulnerability in a listed component is actually exploitable in the product.

Where is it defined?

The baseline is the NTIA report The Minimum Elements for a Software Bill of Materials (2021). It names the required data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, timestamp), requires automation support through a standard format, and describes the practices around generation and distribution. CISA has continued that work.

In the EU the Cyber Resilience Act makes the SBOM a legal requirement for products with digital elements. Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies. The SBOM belongs to the technical documentation (Annex VII). In Germany the BSI Technical Guideline TR-03183 Part 2 specifies the fields, formats and depth it expects, which is more detailed than the regulation itself.

What it means in practice

For application code built with a package manager, an SBOM is a build step. For embedded products it is the hard part of CRA compliance:

• Incomplete inventories. Yocto and Buildroot generate SPDX for the packages they build, but vendor SDKs, binary blobs, bootloaders, radio stacks and libraries copied into the source tree years ago are missing.
• Wrong versions. The SBOM says OpenSSL 3.0.x; the binary on the device identifies as 1.1.1. When we extract firmware in a hardware test, comparing the real binaries with the declared SBOM is one of the first things we do, and the two rarely match.
• Top-level only. The CRA minimum is the top-level dependencies, but most CVEs sit in transitive ones.
• A document, not a process. The SBOM is generated once for the technical file and never regenerated after the next firmware release. It needs to be rebuilt with every build and matched against vulnerability feeds continuously, with VEX statements for the matches you have assessed.
• No identifiers. Components listed by name only, without PURL or CPE, cannot be matched automatically.

Zyberum verifies SBOMs against extracted firmware, builds the vulnerability-handling process the CRA requires around them, and checks SBOM depth and format in CRA gap analyses for device manufacturers.

Common misunderstandings

An SBOM does not make a product secure; it makes it possible to know what is in it. It is not required to be public under the CRA; it must exist and be available to authorities, and customers increasingly ask for it in contracts. And the output of a binary scanner is an estimate of an SBOM, not the SBOM itself; the authoritative list comes from the build.