Software Bill of Materials

The value of an SBOM is measured entirely on the day a critical vulnerability is disclosed in a transitive dependency. The question is "which of our 400 services ship this library, at what version, and which are internet-facing", and the difference between answering in minutes and answering in a fortnight is whether that inventory was generated at build time.

Log4Shell was the event that turned this from compliance paperwork into procurement language, and it is now a contractual requirement in a growing number of enterprise and public-sector deals.

Two details separate a useful SBOM from a box-tick. It must be generated during the build, from the resolved dependency graph, not scanned afterwards from a manifest that lists ranges rather than resolutions. And it must be stored and queryable across the estate — an SBOM sitting beside its artifact answers nothing at scale; the query you need is across every deployed version.

Its limits are worth stating plainly: an SBOM lists what is present, not what is reachable or exploitable, and vulnerability counts drawn from it will overstate real risk unless paired with reachability analysis.