Software bill of materials (SBOM)

The analogy with the bill of materials from manufacturing is intentional and goes a long way. A car manufacturer knows which supplier delivered which part in which batch and can carry out a targeted recall in the event of a material defect. For software, this matter of course did not apply for a long time. A typical web application today contains more third-party code than its own, spread across hundreds of direct and transitive dependencies. Without an inventory, the question of which third-party parts a product contains remains unanswerable.

What an SBOM contains

In 2021, the US National Telecommunications and Information Administration (NTIA) defined the so-called minimum elements, which remain the most widely used reference for the minimum content to this day. They are divided into three blocks: the data fields per component, the requirements for automation and the process requirements.

The document names the following baseline data fields per component:

• Supplier name — the name of the organisation or person providing the component.
• Component name — the designation of the component itself.
• Version of the component — the exact version, without which any vulnerability mapping is worthless.
• Other unique identifiers — unique identifiers such as the package URL (purl) or CPE, which make machine mapping possible in the first place.
• Dependency relationship — the relationship between the components, i.e. which element contains which.
• Author of SBOM data — who created the document.
• Timestamp — when it was created.

In addition, there are the automation requirements — the SBOM must be available in a machine-readable standard format and be capable of being generated and processed automatically — and process requirements, for example that a new SBOM is created for each new software version and that it is defined how deep the dependency chain is mapped.

In July 2026, the US agency CISA and a number of international partner agencies published a revised version of these minimum elements — the first complete update of the starting point set in 2021. The extensions aim, among other things, at additional fields such as cryptographic hashes and licence information.

The established formats

Two formats have become established internationally. Both are open, machine-readable and accepted by regulators.

The functional differences have shrunk over the years. Both formats map the same core content and carry purl and CPE identifiers. What still distinguishes them today is their focus, governance origin and the surrounding tool landscape. For the choice of format in a specific project, pragmatic criteria are therefore usually decisive: which format do your own customers expect, and which is better supported by the tool chain in use? Conversion between the two is possible, but not always lossless.

Incidentally, a common error is the assumption that ISO/IEC 5962:2021 describes the current SPDX version. The standard reflects SPDX 2.2.1; anyone who refers to it in a contract is thus naming this version, not the 3.x series.

Regulatory context

The rise of the SBOM from a niche topic to a requirement took just a few years and was driven largely by regulation.

Executive Order 14028. The US presidential executive order "Improving the Nation's Cybersecurity", issued in May 2021, obliged suppliers of software to US federal agencies to provide an SBOM. It triggered the NTIA minimum elements and made the term known beyond the security community. NIST has documented the accompanying work on software supply chains.

EU Cyber Resilience Act (CRA). The European regulation on horizontal cybersecurity requirements for products with digital elements entered into force on 10 December 2024. The obligations apply in stages: Chapter IV on the notification of conformity assessment bodies applies from 11 June 2026, the reporting obligations for actively exploited vulnerabilities and severe incidents from 11 September 2026, and the remaining main obligations from 11 December 2027. The CRA requires manufacturers to keep a bill of materials of the software components in a commonly used, machine-readable format. SPDX and CycloneDX both meet this format requirement.

NIS2 and national requirements. In addition, the NIS2 Directive addresses supply chain security from the operator's perspective. In Germany, the technical guideline TR-03183 of the Federal Office for Information Security (BSI) specifies the requirements for SBOMs and in parts goes beyond the minimum standard.

For mid-sized manufacturers, the consequence is tangible: anyone placing products with digital elements on the market in the EU will have to keep a component bill of materials. For service providers and agencies, in turn, expectations are shifting — customers will increasingly expect the SBOM as part of the delivery, not as a chargeable extra.

Generation in the build process

An SBOM maintained by hand is out of date on the day it is completed. The practical route is automatic generation as a step in the build pipeline, so that the matching bill of materials is created with each artefact.

• Syft (from Anchore) analyses container images, file systems and directories and produces SBOMs in both common formats. Particularly widespread in container-based environments.
• cdxgen produces CycloneDX SBOMs for a wide range of programming languages and package managers and thus covers polyglot projects.
• In addition, there are language- and ecosystem-specific tools as well as functions directly in build tools and container registries.

The timing is decisive: an SBOM generated from the built artefact reflects what is actually delivered. An SBOM derived solely from manifest files in the source code reflects the intention. Both have their place, but only the former holds up in an emergency. Retention is just as important: the SBOM must be assigned to the delivered version and remain findable throughout its entire life cycle, otherwise it is missing exactly when it is needed.

A real-world example: Log4Shell

The practical benefit became suddenly visible in December 2021. With CVE-2021-44228, a critical vulnerability was published in the Java logging library Apache Log4j, which became known as Log4Shell. The library is extremely widespread and found its way into countless applications as a transitive dependency — included not directly but via other components that in turn used Log4j.

The most pressing question in the days that followed was neither how dangerous the gap was nor how to close it. Both were quickly clarified. The question was: where is the library in the first place? Organisations with a complete, version-accurate component inventory could answer it with a query. Everyone else searched manually through applications, container images and archives — in some cases for weeks, in some cases with the unsatisfactory result of not knowing for sure. Precisely this difference is the business value of an SBOM.

Benefits beyond security

Vulnerability handling is the most prominent use case, but not the only one.

• Licence compliance: which open-source licences are contained in the product, and are they compatible with your own distribution model? Copyleft licences in a proprietary product are an economic risk that goes undetected without an inventory.
• Purchasing and supplier assessment: an SBOM makes it possible to compare how current and how well managed the component base of a purchased product is.
• Technical assessment in acquisitions: in due diligence reviews, a reliable bill of materials replaces laborious manual analyses.
• Internal standardisation: across several products, the comparison shows where the same task is solved with five different libraries.

Limits and misconceptions

An SBOM is an inventory, not a security assessment. It states what is contained — not whether it is secure. The assessment only comes from matching against vulnerability databases, and this matching needs current data and a process that reacts to hits. An SBOM that nobody evaluates creates effort without benefit.

Second, not every hit is relevant. A vulnerable library in the product does not necessarily mean that the product can be attacked — the affected code path may never be executed. For this distinction there is the complementary concept of VEX (Vulnerability Exploitability eXchange), with which manufacturers document whether a known vulnerability can actually be exploited in the specific product. Without this addition, teams drown in findings that are not findings at all.

Third, completeness is limited. Statically linked code, supplied binaries without package metadata and components loaded at runtime often escape automatic capture. An SBOM is a very good approximation, not complete proof.

Fourth, adoption itself is an open issue: formats, retention and exchange between manufacturer and customer have been solved technically, but are not yet established organisationally in many supply relationships.

Outlook

The direction is foreseeable. When the CRA's main obligations take effect at the end of 2027, the component bill of materials will become a prerequisite for market access for a large proportion of products with digital elements sold in the EU. At the same time, standardisation bodies and initiatives such as the OpenSSF are working on closer alignment between the formats and the regulatory requirements, so that one document can serve several jurisdictions.

In terms of content, an expansion of the concept is emerging: alongside the classic software bill of materials, related bills of materials are being created for hardware, for the cryptographic methods used in a product and for the components of AI systems. The common denominator remains the same — making it traceable what a product consists of.

Frequently asked questions

Who needs an SBOM?

Every organisation that produces or distributes software, and increasingly also operators who have to provide information about the components they use. With the Cyber Resilience Act, the bill of materials becomes mandatory for products with digital elements in the EU.

SPDX or CycloneDX — which format?

Both are standardised and accepted by regulators. In practice, customer requirements and tool support decide. Conversion is possible, but not always lossless.

How often does an SBOM need to be renewed?

With every version of the software. Since dependencies can change with every build, automatic generation in the pipeline is the only practical way.

Does an SBOM replace a vulnerability scan?

No. The SBOM is the data basis, and matching against vulnerability databases is the evaluation. The two belong together, supplemented by a statement on actual exploitability via VEX.

Does an SBOM have to be published?

Not necessarily. It can be handed over confidentially to customers, testing bodies or authorities. The regulation requires availability to certain recipients, not general disclosure.

The specification and the tool landscape of the CycloneDX format are documented at cyclonedx.org.