SBOM (software bill of materials)

A software bill of materials is a structured list of what an application is made from: each component, its version, where it came from, the licence attached to it, and how the components relate to one another. It is written in a standard machine-readable format, in practice SPDX or CycloneDX, rather than assembled by hand as a document. The premise is simple enough. A modern application is mostly other people’s code, and an inventory is the difference between knowing what you ship and estimating it. Regulators and large customers now ask for one by name, which is why the term turns up in procurement paperwork rather than only in engineering conversations.

The commercial driver is response time. When a serious vulnerability in a widely used library is published, the first question every customer asks is whether you are affected, and the second is how quickly you can answer the first. Without an inventory that becomes an archaeology exercise across repositories and container images. With one it is a query. The Cyber Resilience Act also turns this into an obligation for manufacturers placing products with digital elements on the EU market, which moves it from good practice into a compliance artefact.

What separates a useful inventory from a generated file

• Produced at build time from the artefact that actually ships, not from a manifest describing what was intended. What was built and what the manifest claimed can differ.
• Transitive rather than direct only. The dependency that hurts you is usually several levels down and nobody on the team ever chose it.
• Stored per release, so you can answer a question about the build a particular customer is running instead of a question about your main branch.
• Consumed by something. An inventory that is generated and never matched against an advisory feed is a file rather than a control.

An inventory tells you a vulnerable component is present; only reading your own code tells you whether the vulnerable function is ever called.