SBOM: the inventory, and what to do with your supplier’s.

A software bill of materials is a formal, machine-readable list of the components that make up a piece of software: their names, versions, suppliers, and how they relate to one another. The analogy is the bill of materials in manufacturing — the parts list for a physical product — and it holds up reasonably well, with one important difference. A car’s parts list is finite and known at the point of assembly. A modern application’s dependency tree is deep, transitive, and frequently unknown even to the team that shipped it.

That gap is the entire argument for SBOMs, and it was made unanswerable in December 2021 by Log4Shell. The vulnerability itself was severe, but the reason it consumed weeks of effort across the industry was not exploitation — it was that most organisations could not answer a simpler question: do we run this at all? Log4j was buried several layers deep inside products bought from vendors, and finding it meant asking those vendors and waiting.

An SBOM turns that question from an investigation into a lookup. That is its whole value proposition, and it is worth being precise about it, because SBOMs are frequently oversold as a security control. An SBOM does not make software safer. It makes software legible, which is a precondition for acting quickly when something in it turns out to be dangerous.

Build-time generation

The SBOM is produced by the build pipeline, from the resolved dependency graph, at the moment the artefact is created. This is the accurate option: the tooling knows exactly what went in, including transitive dependencies and the specific versions resolved on that build.

Post-build analysis

A scanner inspects a finished artefact — a container image, a binary, a package — and infers its contents. Useful, and often the only option for software you did not build, but it is inference. Statically linked libraries, vendored code and rewritten binaries are exactly the cases it handles least well, and they are not rare.

Hand-assembled

Someone writes a list. Treat with the scepticism you would apply to any manually maintained inventory of a system that changes weekly.

The practical question to put to a supplier is therefore not “do you have an SBOM” but “is it generated by your build, and does a new one ship with every release?” An SBOM produced once, by hand, for a procurement exercise describes a version of the product you may never run.

United States. Executive Order 14028 in May 2021 directed federal agencies toward SBOM requirements for software they purchase, which is what prompted the NTIA minimum elements and pulled SBOMs into commercial contracts well beyond government.

European Union. The Cyber Resilience Act entered into force on 10 December 2024 and applies to products with digital elements placed on the EU market. Its timetable matters for planning:

• 11 September 2026 — reporting obligations under Article 14 apply. Manufacturers must report actively exploited vulnerabilities and severe incidents, with an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available.
• 11 December 2027 — the main obligations apply, including the product security requirements that make component inventories a practical necessity.

If you buy software, the second-order effect arrives sooner than the dates suggest: suppliers preparing for the CRA will be producing SBOMs and vulnerability-handling processes through 2026 and 2027, and the ones that are not are telling you something about their maturity.

• Build system compromise. If the pipeline that produces the artefact is subverted, the SBOM is generated by the same compromised process. Provenance attestation — signed evidence of how and where a build ran — is the control that addresses this, and it is a separate ask from the SBOM.
• Dependency confusion and typosquatting. Malicious packages published under names close to legitimate ones, or into public registries that take precedence over private ones.
• Maintainer takeover. A legitimate package whose maintainer account is compromised or transferred. The component name and version look entirely normal in an SBOM.
• Update-channel abuse. The delivery mechanism itself used to push a malicious signed update, which is the pattern behind the most damaging incidents in this category.

None of these are solved by an inventory. All of them are reasons to assess the supplier as an organisation as well as the artefact as an object.