SBOMs in plain English
SBOM stands for Software Bill of Materials. Hardly any software today is written entirely from scratch. Development teams rely on ready-made building blocks: open-source libraries (freely available code components), third-party components, and prebuilt application scaffolding known as frameworks. These building blocks in turn use other building blocks. The result is a dense web of dependencies that nobody can keep track of in their head.
An SBOM makes this web visible. The term comes from manufacturing: a bill of materials is the parts list that itemizes every component of a product. An even more intuitive comparison is the ingredients list on food packaging. If you’re allergic to nuts, you can tell at a glance whether a product contains them. In the same way, an SBOM shows whether a piece of software contains a component that has just been reported as insecure.
“Machine-readable” means the list isn’t a PDF but comes in a standardized data format that programs can evaluate automatically.
How an SBOM works
For each component, an SBOM typically contains:
- Name and version, so it’s clear exactly which release is included.
- Origin, meaning the project or manufacturer the component comes from.
- Unique identifiers that allow the component to be found in vulnerability databases.
- Dependencies, meaning which component uses which other component – across multiple levels.
- Licenses that govern the terms under which the component may be used.
An SBOM is usually generated automatically when the software is assembled, a step known as the build. Common formats are SPDX and CycloneDX. The BSI (Germany’s Federal Office for Information Security) describes what information an SBOM should contain in its Technical Guideline TR-03183-2. If a tool regularly compares the SBOM against vulnerability databases – such as CVE entries – it flags affected products automatically.
A practical example
Here’s a typical scenario: A manufacturer of time clock terminals learns that a critical vulnerability has been discovered in a widely used open-source library. Thanks to its SBOMs, the team can see within minutes that two of its five device generations contain the affected version. It wasn’t included directly but through another library – something nobody on the team had known.
The manufacturer releases a targeted update for the affected devices and informs its customers. Without SBOMs, it would have had to examine every firmware version individually – while attackers might already have been searching for vulnerable devices.
Why does this matter for businesses?
The Log4Shell vulnerability in the Java library Log4j showed at the end of 2021 just how important this overview is: many companies initially didn’t know which of their applications and devices even contained the library. Those with an up-to-date SBOM were able to answer that question much faster – and take targeted action.
What’s more, SBOMs are becoming mandatory. The Cyber Resilience Act requires manufacturers of products with digital elements to document the components those products contain. This includes an SBOM in a commonly used, machine-readable format. At a minimum, it must cover the top-level dependencies – the components integrated directly into the product. The SBOM is part of the technical documentation: manufacturers must provide it to market surveillance authorities upon a reasoned request. They are not required to publish it. These requirements apply from December 11, 2027. Since September 11, 2026, manufacturers have already been required to report actively exploited vulnerabilities and severe security incidents.
Companies that only buy software benefit, too: with their suppliers’ SBOMs, they can assess more quickly whether a new vulnerability or a supply chain attack affects their own organization.
What businesses should do now
- Find out whether you’re affected: Check whether you place products with digital elements on the EU market and therefore fall under the Cyber Resilience Act.
- Generate SBOMs automatically: Have the bill of materials created automatically with every build instead of maintaining it by hand.
- Choose a format: Use a widely adopted format such as SPDX or CycloneDX, and follow BSI TR-03183-2.
- Check continuously: Compare your SBOMs regularly against vulnerability databases and define who takes action when there’s a match.
- Involve your suppliers: Request SBOMs for purchased software and components.
- Verify completeness: Spot-check whether indirectly included components are captured as well.
How Rootsektor can help
As part of our Code Review & Reverse Engineering service, we create and review SBOMs, analyze dependencies for known vulnerabilities, and assess the integrity of your build chain – the process through which your software is created. If no source code is available, as with purchased firmware, reverse engineering helps identify the components it contains. After scoping, you’ll receive a fixed-price quote – you can request it via our Pentest Quote page.