Creating an SBOM for the CRA

Many see the software bill of materials as the big hurdle in the Cyber Resilience Act. They picture an elaborate scan, an expensive tool, and an endless list. A close look at the regulation shows that it asks for less here than the debate suggests. The real difficulty is not creating the list but what comes before it: handling the components you take into your product in the first place.

Under the CRA, a software bill of materials (SBOM) is a formal record of the components included in the software elements of a product, with their details and supply chain relationships. The regulation requires manufacturers to identify and document vulnerabilities and components. One way is to draw up an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies. The SBOM is part of the (internal) technical documentation, not a public document.

Contents

1. What the CRA really requires for the SBOM, and what it does not
2. Do you have to disclose the SBOM to your customers?
3. Why creating the SBOM is not the real hurdle
4. The component list is created at sourcing, not at the end
5. Where do tools sit in the V-model? On the right.
6. What scanners do not see: firmware versions and commercial third-party components
7. What you should do now

What the CRA really requires for the SBOM, and what it does not

The CRA requires the SBOM in a single, clearly defined place. Annex I, Part II, point 1 requires manufacturers to identify and document vulnerabilities and components, and it names the SBOM as the means to do so. Two requirements matter here, and both are narrower than often assumed.

First, the format: it must be commonly used and machine-readable. Widely used formats such as CycloneDX or SPDX meet this requirement. Which fields and elements a CRA-compliant SBOM must contain is not yet settled. The Commission may specify the format and elements of the SBOM by means of implementing acts (Article 13(24)). Until then, the open requirement of the Annex applies.

Second, the depth: the SBOM must cover at the very least the top-level dependencies. At this point, the regulation does not require you to resolve every transitive dependency down to the last level of nesting. That is a real relief. If you know the top level of your components well, you meet the legal minimum depth.

The SBOM also does not stand alone. It belongs in the technical documentation that the manufacturer must prepare anyway. It is therefore one building block of vulnerability handling, not an isolated extra document.

Do you have to disclose the SBOM to your customers?

No. This question causes a lot of uncertainty, yet the regulation's answer is clear. Manufacturers must identify and document which components are included. There is explicitly no obligation to publish the SBOM.

Who gets to see the SBOM depends on who asks:

Who	Gets to see the SBOM?
Market surveillance authority	on reasoned request, where necessary to check conformity
Customer or user	no, there is no obligation to hand it over
Public	no, there is no obligation to publish it

Market surveillance authorities receive the SBOM on request. Further to a reasoned request, the manufacturer provides the SBOM where the authority needs it to check compliance with the requirements. Market surveillance authorities can also request the SBOM as part of a Union dependency assessment. Confidentiality is preserved: information about dependencies is passed on only in anonymized and aggregated form.

There is no obligation to hand the SBOM over to users. The information requirements only ask you to state where the SBOM can be accessed, if you decide to make it available to users at all. Whether you share the SBOM with customers is your decision. You are not obliged to.

The SBOM is therefore first of all an internal tool for the technical documentation and your own vulnerability handling. This shifts the focus away from “How do I show it?” to the question that really matters: how do you produce a reliable list in the first place?

Why creating the SBOM is not the real hurdle

This is our core argument, and it is deliberately a practical assessment, not the text of a standard. Creating the SBOM is not the real hurdle if development is well structured. You may already know which libraries, modules, and purchased building blocks you use while building your product. Then you have the top level of dependencies in your head and usually in your build files. The SBOM only puts this knowledge into a machine-readable format.

It gets difficult exactly where this knowledge about your own components has gaps. Some teams integrate building blocks without recording where they come from, which version they are, and who maintains them. For them, even the best tool helps only to a limited extent. A scanner can uncover a lot after the fact, but it does not replace the decision that must be made before a component is taken in.

That is why, in our view, the effort moves to another point in the development process. It moves forward, to the point where you select and assess a component. That is where the substance of the later list is created.

The component list is created at sourcing, not at the end

Our practical recommendation: add every software component to an inventory at sourcing. Do not reconstruct at the end of development what has been built in. The SBOM then is no longer a project of its own but a by-product of orderly component management.

This approach matches an obligation that the CRA states clearly. If you integrate components sourced from third parties into your product, you must exercise due diligence so that these components do not compromise the cybersecurity of the overall product. This explicitly applies to free and open-source software as well. The CRA describes what this due diligence means in practice:

• verifying the component's conformity (including the CE marking, where the CRA applies),
• checking that the component receives regular security updates,
• consulting relevant vulnerability databases, or
• carrying out additional security tests.

From this we derive a recommendation: assess a component before you take it in, not afterwards when a tool flags it. A library without an update history, a component with open entries in a vulnerability database, or a building block without a clear maintainer is a decision best made before integration. If you work this way, you collect exactly the data the SBOM will later consist of: name, version, origin, and maintenance status.

For the structural framework of such an approach, Germany's Federal Office for Information Security (BSI) offers a German example: its technical guideline TR-03185 on the secure software lifecycle. IEC 62443-4-1 provides an international framework. We cover the special case of free and open-source software in detail in CRA and open-source software.

Where do tools sit in the V-model? On the right.

Software composition analysis (SCA) tools have their place, but it is not at the start. In our view, tools sit on the right side of the V-model: they validate the component list, they do not create it. The list is created on the left, planning side, when you define requirements, source components, and assess them before integration. On the right, verifying side, a scanner then compares what was actually built against this list and reveals deviations.

This order is more than a formality. If you run the tool first and take its findings as the list, you adopt unchecked whatever happened to end up in the code. If you assess first and scan afterwards, you use the tool to check a deliberate decision.

What scanners do not see: firmware versions and commercial third-party components

Tools have blind spots, and you should know them before you rely on a scan. In practice, scanners and SCA tools reliably detect open-source packages, because their metadata is public and well cataloged. With commercial third-party components and specific firmware versions, however, they are often blind. This information is not in searchable code but in the supplier's documents. You must add it to the inventory manually, based on the supplier's information.

What tools reliably detect	What you must add to the inventory manually
open-source packages and libraries	commercial third-party components without public metadata
declared dependencies in build files	specific firmware versions of embedded components
known versions with a catalog entry	information that is only available in supplier documents

This closes the loop to due diligence. To know what is inside a purchased component, you need the supplier's information, and you need it before the tool runs. In our view, a supplier self-declaration is the most practical way to meet this due diligence. It also gives you the information that a scanner does not deliver for commercial components.

Which role in the supply chain is responsible for the SBOM depends on whether you act as a manufacturer, importer, or distributor. We cover this separately in our article on vulnerability and SBOM obligations in the supply chain. In Germany, for example, the VDMA (German Mechanical Engineering Industry Association) has published a document series on supply chain security (in German). It shows how to secure supplier evidence in practice.

What you should do now

The following steps are a practical recommendation derived from the obligations above. They deliberately move the effort forward, so that at the end the SBOM almost creates itself.

• Keep a component inventory, and record each component at sourcing with name, version, origin, and maintainer.
• Assess each component before integration: check conformity, update history, and entries in vulnerability databases.
• For commercial third-party components and embedded firmware, request the supplier's information, ideally as a self-declaration, and add it to the inventory manually.
• Generate the SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies, and include it in the technical documentation.
• Use scanners as a check, not as a source: let the tool compare what was built against your inventory.
• Keep the SBOM ready for the market surveillance authority. Sharing it with customers remains your decision.

If you set up component management this way, you have largely met the CRA's SBOM obligation before you touch a tool. The CRA timeline and transition periods show when the requirements apply to your products.