Modern software consists largely of third-party code: open-source libraries, frameworks and modules from suppliers. When a vulnerability becomes known in one of these components, as with the backdoor in the xz utils compression library in March 2024, the search begins for many organizations: where is this even included? The SBOM, a software parts list, answers this question, much like the list of ingredients on food packaging.
What does an SBOM contain?
In 2021, the US agency NTIA defined minimum elements. For each component, they include:
- supplier and name of the component,
- version and other unique identifiers,
- the dependency relationship, that is, which component is contained in which,
- author of the SBOM data and timestamp.
There are also requirements for automation and processes, for example that a new SBOM is created after every new build or release. In July 2026, CISA, NSA and FBI, together with international partners, published updated minimum elements that replace the 2021 version. According to CISA, new additions include the component's checksum, the license and information about the tool and context of creation.
Formats: SPDX and CycloneDX
Two open formats have become established. SPDX from the Linux Foundation is standardized as ISO/IEC 5962:2021. CycloneDX, backed by OWASP, has been standardized as ECMA-424 since 2024 and describes not only software but also hardware, services and AI models. Both can be generated automatically by common build tools. The German BSI describes requirements for SBOMs in Technical Guideline TR-03183-2, explicitly as preparation for the CRA.
SBOM and the Cyber Resilience Act
The Cyber Resilience Act obliges manufacturers of products with digital elements to identify and document vulnerabilities and components, among other things through a software bill of materials in a common machine-readable format that contains at least the top-level dependencies. Manufacturers do not have to publish the SBOM, but market surveillance authorities can request it.
In practice for SMEs and municipalities
- When purchasing: Ask vendors of specialized applications, firewalls, controllers or apps whether they provide an SBOM and how quickly they inform you about vulnerabilities in components.
- For in-house development: Generate the SBOM automatically in the build and store it with every version.
- In operations: Match SBOMs against vulnerability databases. A VEX document based on CSAF additionally states whether a CVE found is actually exploitable in the specific product.
- In the inventory: Link SBOMs with IT asset management so that it is clear on which systems a product runs.
Limitations
An SBOM does not make software more secure. It makes risks visible. It becomes outdated with every update, is only as complete as the tool that generates it and can reveal confidential details about the architecture. It is therefore important who receives it and how it is kept up to date.
How TOMORIS relates
EXPERTS Cyber Security helps handle vulnerabilities by impact and urgency, even when they are in suppliers' components. The entry supply chain attack provides background on attacks via suppliers.