How a software bill of materials works, which formats to use and how to produce it automatically.
In short
An SBOM (software bill of materials) is a machine-readable list of every component, library and version inside a piece of software. The EU Cyber Resilience Act makes it mandatory for manufacturers of products with digital elements, because you cannot fix vulnerabilities in components you do not know you ship.
A software bill of materials is the ingredient list for software. It records which open source and commercial components a product contains, in which versions, from which suppliers and under which licences. When a new vulnerability is published, the list tells you within minutes whether you are affected, instead of after days of searching through repositories.
This guide is written by Devies, a Gothenburg-based product and engineering consultancy that works with product cybersecurity. It covers what the inventory contains, how the two main formats differ, what the Cyber Resilience Act actually asks for, and how to generate and use the list without manual work.
What does a software bill of materials contain?
A software bill of materials contains, at minimum, the name, version and supplier of each component in a product, plus a unique identifier and the relationships between components.
In practice a useful inventory records:
- Component name and version, for example a specific release of a logging or TLS library.
- Supplier or origin, such as an open source project or a commercial vendor.
- A unique identifier, typically a Package URL (purl) or CPE, so that scanners can match the component against vulnerability databases.
- Dependency relationships, showing which components pull in which others.
- Licence information, useful for legal review even though it is not the main security driver.
- A hash and a timestamp, so you can prove which build the list describes.
A direct dependency is a library your code includes on purpose. A transitive dependency is a library that one of your dependencies pulls in. Most known vulnerabilities in modern applications sit in the transitive layer, which is why a list of only what developers chose is rarely enough for security work.
SBOM formats: SPDX or CycloneDX?
SPDX and CycloneDX are the two widely used machine-readable formats, and both are acceptable choices because the Cyber Resilience Act does not mandate a specific one.
SPDX is maintained by the Linux Foundation and is published as the international standard ISO/IEC 5962:2021. CycloneDX is an OWASP project, standardised as ECMA-424, with a strong focus on security use cases.
SPDX
CycloneDX
Origin
SPDX
Linux Foundation, licence compliance
CycloneDX
OWASP, application security
Standard
SPDX
ISO/IEC 5962:2021
CycloneDX
ECMA-424
Strengths
SPDX
Licences, legal provenance, file-level detail
CycloneDX
Vulnerabilities, VEX, services, lightweight
Common encodings
SPDX
JSON, tag-value, RDF, YAML
CycloneDX
JSON, XML, Protocol Buffers
Typical fit
SPDX
Organisations with licence audits
CycloneDX
DevSecOps teams focused on vulnerabilities
Our practical advice: pick the format your build tools and scanners already support well, and stay consistent across products. Conversion tools exist in both directions, so the choice is rarely a lock-in. What matters more is that the list is complete, generated from the real build and kept current.
What does the Cyber Resilience Act require?
The Cyber Resilience Act requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies.
The Cyber Resilience Act is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. As of October 2026, the timeline published on EUR-Lex and by the European Commission is:
- 10 December 2024: the regulation entered into force.
- 11 June 2026: rules on conformity assessment bodies (notified bodies) began to apply.
- 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe incidents. This obligation already applies.
- 11 December 2027: the main obligations, including the vulnerability-handling requirements in Annex I, apply in full.
The inventory requirement sits in Annex I, Part II, which covers vulnerability handling. A few points are often misunderstood:
- It does not have to be public. The list is part of the technical documentation and must be provided to market surveillance authorities on a reasoned request. Publishing it is optional.
- Top-level dependencies are the legal floor, not a recommendation. For real security work you will want transitive dependencies too.
- The format may be specified later. The Commission can adopt implementing acts on format and elements, so keep your tooling flexible.
- It is ongoing. The obligation follows the product through its support period, so a list produced once for a launch does not meet the intent.
The act is about more than documentation. It frames the inventory as the basis for handling vulnerabilities, which is why the next two sections focus on automation and monitoring.
How do you generate the inventory automatically in CI?
You generate it automatically by adding a step to your build pipeline that produces the list from the actual build artefact, stores it with the release and sends it to a monitoring tool.
A workable pipeline looks like this:
- Generate at build time. Run a generator such as Syft, cdxgen or the CycloneDX and SPDX plugins for Maven, Gradle, npm or .NET on every release build. Generate from the container image or binary as well as from source, because the final artefact can contain components the source manifests do not show.
- Attach it to the release. Store the file next to the artefact in your registry, with the same version number, so you can always answer "what was in version 3.4.1?".
- Sign it. Sign the file, for example with Sigstore Cosign, so that customers and authorities can trust that it has not been altered.
- Validate it. Check that the file is well formed and that required fields such as supplier, version and identifier are present. Fail the build if quality drops.
- Publish it to an inventory platform. Tools such as OWASP Dependency-Track ingest the files for all products and versions in one place.
- Cover third-party software. Ask suppliers of commercial components and firmware for their lists, and include that requirement in procurement contracts.
Avoid generating the inventory by hand or in a spreadsheet. It will be out of date by the next release, and an outdated list gives false confidence.
From inventory to vulnerability management
Vulnerability management (sårbarhetshantering) is the continuous process of finding, assessing, fixing and communicating vulnerabilities, and the inventory is the input that makes it possible.
Once your lists sit in a central platform, it can match every component against sources such as the NVD, the GitHub Advisory Database and OSV. When a new advisory is published, you see which products and versions are affected without starting a manual search.
Three habits separate a working process from a noisy one:
- Triage with context. Not every vulnerable library is exploitable in your product. Record your assessment, ideally as a VEX (Vulnerability Exploitability eXchange) statement, so you do not repeat the analysis.
- Define ownership and deadlines. Decide who fixes what, and how fast, by severity. The Cyber Resilience Act expects security updates to be provided without delay.
- Connect to reporting. Actively exploited vulnerabilities must already be reported under the act. A clear inventory shortens the time from alert to an accurate report.
The inventory tells you what you ship. It does not prove the product is secure. Testing methods such as penetration tests and threat modeling answer different questions, which we compare in our guide to choosing between a pentest, a vulnerability scan and threat modeling.
Keep reading
From our work
Consilium and Devies Cybersecurity+Consilium Safety Group and Devies Cybersecurity+: a partnership for future-proof cybersecurity in fire, flame and gas safety systems.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Is an SBOM mandatory under the Cyber Resilience Act?
Yes, for manufacturers of products with digital elements placed on the EU market. Annex I of Regulation (EU) 2024/2847 requires a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. The main obligations apply from 11 December 2027, but vulnerability reporting has applied since 11 September 2026, so starting the inventory now is the practical choice.
Do we have to publish our SBOM?
No. Under the Cyber Resilience Act the software bill of materials is part of the technical documentation, and you must hand it to market surveillance authorities when they make a reasoned request. You may choose to share it with customers, and many B2B buyers already ask for it in procurement, but public disclosure is not a legal requirement.
Should we use SPDX or CycloneDX?
Either works, because the Cyber Resilience Act does not mandate a format. SPDX (ISO/IEC 5962:2021) is strong on licences and provenance. CycloneDX (ECMA-424) is strong on security use cases such as vulnerability data and VEX. Choose the format your build tools and scanners support best, use it consistently across products, and keep tooling flexible in case implementing acts specify details later.
How often should an SBOM be updated?
Generate a new one for every release build, automatically in your CI pipeline, and keep it stored with that release. The list should always describe exactly what was shipped in each version. Monitoring then runs continuously against those stored lists, so you learn about new vulnerabilities in old versions that customers still run, not only in the latest build.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- Cyber Resilience Act, European Commission
- SPDX specification, Linux Foundation
- CycloneDX specification, OWASP
- Devies Cybersecurity+
- Devies, The Cyber Resilience Act: Alignment Workshop
