Software Bill of Materials (SBOM): What the CRA Requires and How to Build One
An SBOM, or Software Bill of Materials, is a detailed list of every SOFTWARE component that makes up a digital product: libraries, open source packages, and third-party dependencies. Under the Cyber Resilience Act, manufacturers of products with digital elements must identify and document these components, covering at the very least their top-level dependencies. An SBOM lists what is inside the code, not what is inside the box.
What’s the difference between a BOM and an SBOM?
A traditional Bill of Materials lists physical parts: screws, circuit boards, cables, enclosures. Manufacturers with experience in BOMs for hardware sometimes assume the SBOM is a natural extension of the same process. It is not. An SBOM applies the same inventory logic to software instead of hardware: every library, every open source package, every dependency the product relies on to run.
Building one requires different tools and a different process entirely. A hardware BOM comes from a parts list maintained by procurement.
An SBOM comes from scanning the actual codebase, container images, or compiled binaries to detect what is really inside,
which is frequently more than what any single engineer remembers including.
What does the CRA actually say about the SBOM?
The SBOM requirement sits in Annex I, Part II of the CRA, the section on vulnerability management requirements, not in the part covering product design. The regulation treats the SBOM as an operational security tool rather than a documentation formality.
The text requires manufacturers to identify and document vulnerabilities and components in products with digital elements, including by drawing up a software bill of materials in a commonly used, machine-readable format covering, at the very least, the top-level dependencies of the products. The CRA does not require manufacturers to make the SBOM public. It must form part of the technical documentation under Annex VII and be made available to market surveillance authorities on a reasoned request.
The obligation to report actively exploited vulnerabilities starts earlier, on 11 September 2026.
Full application of the CRA, including the SBOM requirement, applies from 11 December 2027.
Meeting that reporting deadline requires knowing which components a product contains, which means SBOMs need to be operational well before the 2027 deadline for products already on the market.
Which standards can I use to build my SBOM?
The CRA does not name a required format. It leaves room for the European Commission to specify one through future implementing acts. In practice, two formats dominate:
CycloneDX, developed by OWASP with native support for security use cases,
and SPDX, standardised as ISO/IEC 5962:2021 and historically stronger on license compliance.
Germany’s BSI has published the most detailed technical reference available today, the guideline TR-03183-2. It specifies which versions of CycloneDX and SPDX are acceptable, which fields are required at both the SBOM and component level, and a resolution depth that goes beyond the CRA’s minimum of top-level dependencies.
Converting between formats is not neutral. Moving a SBOM from CycloneDX to SPDX can lose data, such as CycloneDX’s native VEX information. When an authority requests a specific format, regenerating the SBOM from the source produces a more reliable result than converting an existing file.
Why can’t I just keep my SBOM in a spreadsheet?
A spreadsheet is not machine-readable in the sense the CRA requires. It cannot be automatically cross-checked against vulnerability databases such as the NVD, OSV, GitHub Advisory Database, or the European Vulnerability Database that ENISA launched in May 2025. Every new vulnerability disclosure would require someone to manually search a static file for matching component names and versions.
A properly structured SBOM in CycloneDX or SPDX format integrates with tools that perform this correlation automatically and continuously. When a new vulnerability is published for a component used anywhere in the product, the tool flags it without anyone having to search for it.
If I use an app, can I generate the SBOM automatically and forget about it?
No. A tool can generate an accurate SBOM at a single point in time, but the document needs to stay current as the product changes: a new version, a new dependency, an updated library. ENISA’s 2025 survey found that 78% of organisations had already started their SBOM adoption process, with 44% still in a pilot or limited deployment phase, which reflects how much work sits between initial generation and an operational, ongoing practice.
Keeping a SBOM current typically means regenerating it with every new build rather than producing it once and filing it away. BSI’s TR-03183-2 guidance goes further: it expects a new SBOM whenever any component changes, even without a new product version, and whenever new information about the product’s composition comes to light.
What is VEX, and why does the SBOM need it?
VEX, short for Vulnerability Exploitability eXchange, is a document that states whether a known vulnerability in a software component actually puts a specific product at risk. A SBOM lists components. It does not say whether a known vulnerability in one of those components is exploitable in the way that product uses it, and most vulnerabilities found in a component never are.
For each known vulnerability affecting a component in the SBOM, VEX states whether the product is affected, not affected, already fixed, or still under investigation. Where a SBOM stays relatively stable between versions, VEX changes as new vulnerabilities are disclosed and investigated.
The practical effect is a sharp reduction in noise. Every newly disclosed vulnerability, tracked under a public identifier known as a CVE (Common Vulnerabilities and Exposures), triggers an alert across every product that includes the affected library, regardless of whether the vulnerable code path is ever reachable. Without VEX, security teams have to investigate each of these alerts manually. With VEX in place, only the vulnerabilities that genuinely apply to the product reach that queue. CycloneDX supports VEX natively, and tools built around SBOM monitoring increasingly generate and consume it as part of the same workflow.
Tools and technical options to build an SBOM
Generating a SBOM requires choosing between open source tools and commercial platforms, a decision that depends on the size of the organisation and the number of programming languages and ecosystems the product uses.
Source code and dependency scanning is the most common starting point. These tools read manifest files and lockfiles (package.json, requirements.txt, pom.xml, and similar) to resolve the full dependency tree of an application, including transitive dependencies that do not appear in any single file.
Container image analysis scans the layers of a Docker or OCI image to identify every package installed inside it, which matters because a container often includes operating system packages and libraries that never appear in the application’s own source code.
Binary and firmware analysis addresses a harder case: products where the source code is not available or not practical to scan, such as compiled firmware on an embedded device. These tools inspect the compiled artifact directly to identify embedded libraries and components.
The most accurate SBOMs come from generation at build time, directly from the resolved dependency tree, rather than reconstructing the component list after the fact from a finished artifact. A SBOM generated retroactively can miss components that were present during the build but stripped out before packaging, or fail to capture the exact versions actually compiled into the release.
Commercial platforms add governance features on top of generation: continuous monitoring, policy enforcement, audit trails, and integration with procurement workflows. For ongoing vulnerability correlation, OWASP Dependency-Track is a widely referenced open source platform that ingests SBOMs and continuously re-checks them against multiple vulnerability intelligence sources, including the NVD, OSV, and GitHub Advisory Database, as new CVEs are published, without requiring a full rescan of the product.
The vendor landscape for SBOM tooling changes quickly, and claims about specific commercial products, including reported security incidents involving particular tools, should be checked against the vendor’s current documentation rather than taken at face value.
The SBOM requirement under the CRA sets a legal floor: machine-readable format, top-level dependencies, available to authorities on request. Meeting only that floor leaves gaps that become visible the moment a product needs to demonstrate vulnerability traceability under real regulatory pressure.
Building a SBOM process that holds up under the CRA, integrates with vulnerability handling obligations, and stays current through every product version and every new VEX disclosure is closer to a continuous engineering practice than a one-time compliance task. Tell us about your project.
