What Is an SBOM? The Software Bill of Materials
What is a Software Bill of Materials (SBOM)? A SBOM, short for Software Bill of Materials, is a machine‑readable bill of materials listing all components, libraries, and dependencies of a software package, including their versions. It answers the question of what a product is actually made of. Since the Log4Shell vulnerability and with the Cyber Resilience Act, the SBOM has moved from a nice‑to‑have to a reliable requirement for manufacturers.
Key Takeaways
- What it is: A complete, machine‑readable list of all software components, comparable to an ingredients list.
- Purpose: When a new vulnerability emerges, you can check within minutes-rather than days-which products contain the affected component.
- Why now: The Cyber Resilience Act (EU Cyber Resilience Act) makes transparency about software components a manufacturer requirement, phased in through 2027.
Why is an SBOM actually needed?
Modern software consists largely of foreign code: open-source libraries, frameworks and dependencies that themselves bring further dependencies. Without a bill of materials, often no one knows exactly what is in a product. This very blindness became a problem with Log4Shell when the widely used library Log4j had a critical vulnerability.
The key question at the time in every company was: Which of our applications actually contain Log4j? Those who maintain an SBOM for each product answer this via a query. Those who do not have one have to search manually through the entire software landscape. An SBOM turns a days‑long search into a targeted check.
The vulnerability CVE-2021-44228 in the library Log4j made 2021 visible how few organizations know their software components
Source: NIST NVD / BSI
What Constitutes a Viable SBOM
An SBOM is more than a PDF attachment. To add value, it must be machine‑readable and can be evaluated automatically. Two formats have become established: SPDX from the Linux ecosystem and CycloneDX from the application security domain. Both describe components, versions, and relationships in a structured way.
What’s crucial is also currency. An SBOM that is created only at release and never updated becomes obsolete with each change. It makes sense to generate it automatically during the build process, so each version gets its own accurate bill of materials. Only then can a new vulnerability be reliably matched against the inventory.
Getting Started with SBOM
- ✓Automatically generate SBOMs in the build process, don’t maintain them manually
- ✓Choose a machine‑readable format, such as SPDX or CycloneDX
- ✓Store SBOMs centrally and compare them with vulnerability data
- ✓Require an SBOM from purchased software
What the Cyber Resilience Act Changes
The Cyber Resilience Act (Verordnung (EU) 2024/2847) requires manufacturers of products with digital elements to ensure security throughout the product lifecycle. Annex I, Part II explicitly requires manufacturers to create a Software Bill of Materials (SBOM) in a commonly machine‑readable format that covers at least the top‑level components and dependencies. It is part of the technical documentation and must be available to regulators, without mandating publication to end users.
The requirements are phased in: reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026, and the remaining CRA obligations from December 11, 2027. For manufacturers, this means setting up the SBOM as a permanent part of the development process. Those who integrate it early can meet upcoming obligations with far less effort than retrofitting later.
How an SBOM Stays Alive in Operations
An SBOM only reveals its value during active operation. New vulnerabilities emerge daily, so the bill of materials must be continuously cross‑checked against up‑to‑date vulnerability databases. Only this automated comparison turns a static list into an early‑warning system that instantly flags affected products whenever a new flaw appears.
Additionally, the VEX (Vulnerability Exploitability eXchange) concept has gained traction. It allows manufacturers to indicate whether a vulnerability listed in the SBOM can actually be exploited in a specific product. This prevents false alarms when a vulnerable library is present but the vulnerable code isn’t actually used. Together, SBOM and VEX provide a realistic picture of the true attack surface.
Frequently Asked Questions
Every question is locked. A tap unlocks the answer.
What is the difference between SPDX and CycloneDX?
Both are established SBOM formats. SPDX originates from the open-source realm and is widely standardized, while CycloneDX comes from application security. Both are machine-readable and suitable for matching with vulnerability data.
Will the Cyber Resilience Act make SBOMs mandatory?
Yes. Annex I Part II of Regulation (EU) 2024/2847 obliges manufacturers to create and retain a machine-readable Software Bill of Materials (SBOM) in the technical documentation. Public release to end customers is not required.
Is a single SBOM sufficient per product?
No. Each software version should have its own SBOM, because components and versions change with every update. It is best generated automatically in the build process.
Does an SBOM help against attacks?
It does not prevent an attack, but it significantly shortens the response time. When a new vulnerability emerges, the SBOM instantly shows which products are affected, instead of triggering a lengthy manual search.
Should one require SBOMs from suppliers?
Yes. Anyone buying or integrating software should request an SBOM to gain visibility into their own supply chain. Without this information, part of the risk remains invisible.
Editor’s Picks
Editor’s PickTwo Joomla Upload Vulnerabilities Added to CISA KEVEditor’s PickThe concentration risk no supplier audit sees
More from the MBF Media Network
Digital ChiefsFive Points Where Supply Chain Software FailscloudmagazinWhat the Mittelstand can really take over by 2026MyBusinessFutureDigital Product Passport: What Manufacturers Must Do
