Article partially generated by artificial intelligence.
TL;DR: An SBOM (software bill of materials) is a list of the libraries, modules and versions a product is built from. From 11 December 2027, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. It does not have to be public, but it must be part of the technical documentation. For device makers it is also what makes the CRA’s 24-hour vulnerability reporting deadline, already in force, achievable.
This guide complements our overview of what NIS2 and the CRA require from companies that own software.
Key facts:
A bill of materials is to software what an ingredients list is to food. It shows which ready-made parts the software is built from: open-source libraries, supplier components, real-time operating systems, drivers. For each part it records the name, version, supplier and dependencies.
Manufacturers need a bill of materials for three reasons. First, the Cyber Resilience Act requires it. Second, without one you cannot quickly tell whether a new flaw in a popular library affects your product, and since 11 September 2026 an actively exploited vulnerability must be reported within 24 hours; we explain the CRA’s 24-hour reporting deadline separately. Third, customers covered by NIS2 increasingly ask suppliers for one as part of supply chain checks.
Under Regulation (EU) 2024/2847, manufacturers must identify and document the vulnerabilities and components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It belongs in the technical documentation that the manufacturer keeps and provides to market surveillance authorities on request.
The regulation does not prescribe a format, but in practice the choice is SPDX or CycloneDX. The NTIA minimum elements for an SBOM remain a good baseline for the data to include: supplier name, component name, version, unique identifiers, dependency relationships, author of the data and a timestamp.
SPDX is maintained by the Linux Foundation, is an international standard (ISO/IEC 5962:2021) and is strong on licensing. CycloneDX originated at OWASP and is security-focused: it handles vulnerability data well and supports VEX documents, in which a manufacturer explains that a given vulnerability does not affect the product. Both meet the “commonly used, machine-readable” requirement. The choice usually depends on your existing tools and what your customers expect.
For a web application, standard tools can generate a bill of materials from the package manager in minutes. Devices and machines are harder:
That is why it should be generated automatically on every build, not by hand once a year. CISA’s resources cover VEX and sharing SBOMs with customers.
The first time a bill of materials meets a vulnerability database, the result is usually a shock: hundreds of alerts for a single product. Most of them are not real threats. A library may contain a vulnerable function the product never calls, or the flaw may depend on a configuration the device does not use.
VEX (Vulnerability Exploitability eXchange) exists for exactly this. It is a document in which the manufacturer gives a status for each known vulnerability, such as “not affected”, “affected, fix in progress” or “fixed in version X”. VEX saves time for your team and for customers who receive it, because they do not have to analyse every alert themselves. CycloneDX supports VEX directly, and CISA’s materials describe minimum requirements for such documents.
Every “not affected” decision should have a documented rationale. If the vulnerability turns out to be exploited after all, the market surveillance authority will ask on what basis it was dismissed.
The Cyber Resilience Act does not require publishing it, but industrial customers, especially those covered by NIS2, increasingly ask for it during supplier assessments. Three models are common. First, it stays in the technical documentation and goes to authorities on request. Second, customers get it under a non-disclosure agreement, for example through a customer portal. Third, it is public, which mainly makes sense for open-source software or products where transparency is a selling point.
Whatever the model, the bill of materials should be tied to a specific product version and updated with every release. A two-year-old list for a device that has since received five updates is worse than none, because it gives a false sense of knowing what is inside.
Each of these mistakes can be avoided when the process is designed. They are most expensive to fix under time pressure, for example on the day you have 24 hours to find out whether a new vulnerability affects a product sold three years ago.
A heating controller maker sells three generations of devices. The latest runs firmware on a real-time operating system, with a networking stack from the chip vendor and a dozen open-source libraries, including a TLS library. On top of that come a mobile app and a cloud backend that delivers updates.
The full picture needs several SBOMs: one for each supported firmware generation, one for the mobile app and one for the backend. Firmware is the hardest, because some libraries were copied into the repository years ago and the chip vendor’s SDK contains binaries. So the team generates SBOMs automatically in the build system and fills the gaps from SDK documentation and a manual review of third-party code folders.
The payoff comes with the first serious alert. When a critical vulnerability appears in the TLS library, the team establishes within minutes that it affects two of the three generations, checks whether the vulnerable function is used and prepares a VEX document for customers. Without one, the same analysis would mean searching repositories and asking former employees which library version went into which firmware release.
Sanddev sets up automated bill-of-materials generation in the build pipeline, untangles dependencies in older codebases and connects it to vulnerability monitoring. See our approach to building SBOM generation into your build pipeline.
An SBOM (software bill of materials) is a list of the libraries, modules and versions a product is built from, with suppliers and dependencies. It lets a manufacturer check quickly whether a new vulnerability affects its product.
Yes. From 11 December 2027, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up a machine-readable SBOM covering at least top-level dependencies, as part of the technical documentation.
No. The Cyber Resilience Act does not require publishing it. The manufacturer keeps the bill of materials in the technical documentation and provides it to market surveillance authorities on request, and may choose to share it with customers.
Both meet CRA requirements. SPDX is the ISO/IEC 5962:2021 standard and is strong on licensing; CycloneDX (ECMA-424) is security-focused and supports VEX documents. The choice depends on your tools and customers.
Mature open-source SBOM tools can generate SPDX or CycloneDX files from package managers and container images. For C and C++ firmware, expect to combine build-time generation with manual entries for copied libraries and binary SDK components.
OWASP Top 10 is the list of the most serious risk categories in web applications. AI-built apps, for example in Lovable on a Supabase database, usually fail exactly where it says – above all in access control. Here is a 12-point checklist to run before an auditor asks.
Third-party risk management is now a legal duty for companies covered by NIS2. Supply chain security is one of the minimum risk-management measures in the directive, and it reaches the companies that write, maintain and host your software.
The Cyber Resilience Act (CRA) has required, since 11 September 2026, manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents. An early warning is due within 24 hours of becoming aware, a full notification within 72 hours and a final report later.
