A manufacturer's first SBOM is almost always created by hand: someone sits down, goes through the dependencies, and enters names and versions into a spreadsheet. The result is correct — for exactly one build. By the next patch release it no longer is, and nobody notices, because the spreadsheet lives in a different tool than the code.
That is the core of the problem: a bill of materials maintained alongside the build is a parallel process. Parallel processes drift.
What the CRA requires — and what it does not
In Annex I, Part II, the Cyber Resilience Act requires manufacturers to identify and document the components contained in the product and their vulnerabilities. This explicitly includes a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies.
Three points are regularly overlooked:
"Machine-readable" rules out the spreadsheet. A PDF or an Excel file does not meet the requirement. What is meant are formats such as SPDX or CycloneDX.
"At least top-level" is a minimum, not a goal. For your own vulnerability work, transitive dependencies are often the more interesting ones — that is where the libraries sit that nobody consciously chose.
The SBOM is not a delivery artifact for everyone. It is part of the technical documentation and must be made available to market surveillance authorities on request. The widespread concern that you have to publish your bill of materials does not reflect the legal text.
The single place where the truth lives
A reliable SBOM has exactly one property: it is generated from the same source as the artifact itself. Everything else is a description of the desired state.
For embedded projects, this usually means:
- Yocto / OpenEmbedded: The bill of materials is created from the image recipe, not from the integrator's memory. The layer and recipe structure already knows versions and licenses.
- Buildroot: The package set of the configuration is the source; the configuration therefore becomes an evidence artifact and must be versioned with the release.
- Application code: The lockfiles of the respective toolchain are the authoritative source, not the manifest file with its version ranges.
- Manually integrated libraries: the problem case. Anything that sits as a copy in the repository does not show up in any automated inventory and must be captured explicitly — ideally with the goal of eliminating these cases.
The SBOM is generated in the build and stored together with the release artifact, with the same version identifier. An SBOM without an unambiguous link to a firmware version is worthless when it matters: the question is never "which libraries do you use?" but "which library is in the version running at this customer?".
From artifact to process
The bill of materials alone does not yet deliver value. It becomes a tool only when it connects at two points:
Vulnerability monitoring. New advisories must be checked against the SBOMs of the shipped versions — automatically, not ad hoc. This is exactly where the machine-readable format pays off.
Supplier management. Third-party components need a commitment on how long they will be maintained. A library without a recognizable maintenance path is a product risk waiting to happen — and in 62443-4-1 a topic for the Security Management practice. Selection is the cheapest lever: a carefully chosen, actively maintained open-source component in a current version saves more vulnerability work than any downstream scanning.
If you are looking for more concrete guidance on content and level of detail, you will find it in the BSI guideline TR-03183 — in several places it is stricter and more precise than the legal text itself.
What is actually asked in an audit
Not: "Do you have an SBOM?" But: "Show me the SBOM for firmware 2.4.1, and show me how it was created." Whoever can point to the build job at this point is done. Whoever points to a document management system starts explaining.
Technical assessment, not legal advice. For a binding interpretation in an individual case, please consult the legal text and legal counsel.
Sources
- CRA Annexes I–VIII — Essential Requirements & Product Lists
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — consolidated legal text
- CycloneDX Specification Overview (OWASP)
- SPDX — System Package Data Exchange (Linux Foundation)
- BSI TR-03183 — Cyber resilience requirements for manufacturers and products (Part 2: SBOM)
- IEC 62443-4-1:2018 Ed. 1.0 — Secure product development lifecycle requirements
This article was originally published in German on the Alsensio Cybersecurity Hub.
