An SBOM is sold to you as a security document. That is the smallest thing it is.
The acronym stands for Software Bill of Materials, and the simplest way to picture one is the way CISA describes it: a list of ingredients, the label on the tin. Modern services are not written so much as assembled; a single application pulls in dozens, often hundreds, of ready-made open-source building blocks, the shared bundles of code that engineers call libraries or packages. The SBOM is the label that says which ones, and at what version. It exists because regulators wanted a record of what was inside a piece of software when something went wrong.
The phrase is older than software. A bill of materials is what a factory keeps so that any worker can see what a thing is made from; we simply bolted an "S" onto a two-century-old idea. The interesting part is what makes a bill of materials worth keeping at all. When Joseph Whitworth published the first national screw-thread standard in 1841, interchangeable parts stopped being a promise and became real, because a bolt from one workshop now fitted an assembly from another. Reuse only works once everyone is measuring against the same gauge.
One SBOM is an inventory. Fifteen thousand is a map.
The reframe matters because the two objects belong to different categories. One bill of materials answers a question about one service: what is this thing made of? That is an inventory, and an inventory looks backward.
Stack 15,594 of them on a shared key and the object changes. The shared key is the Package URL, or purl, a structured identifier that names a component the same way everywhere, so that pkg:npm/express@4.18.2 means the same thing whether it appears in a service at the Home Office or one at HMRC. The purl is Whitworth's gauge for software, and across the UK public-sector estate it sits on every single row. When every service describes its ingredients in one vocabulary, the inventories stop being a pile of separate records and become a single picture you can ask questions of. It is not a record of what you have but a map of what everyone builds on. And a map is a reuse engine.
I should say where the map came from, because the shape of the thing explains the shape of the idea. It started as a small habit. Late one night I wanted to know which government teams were publishing code at all, so I wrote something to list every government repository and rebuild the list each night. Eight years later it is a catalogue of more than twenty thousand public-sector repos, still regenerating in the dark. The first article in this series made the case for coding in the open at all. The second added semantic search, so you could ask the catalogue "who else in government has built a case management system?" and get an answer. This third one adds the dependency layer, and the reason any of it exists is the day job: reducing duplication and helping the public sector reuse what it has already built rather than pay to build it twice.
That layer arrived yesterday, when govreposcrape PR #330 added eight new tools over the aggregate SBOM of the government software estate, reachable through MCP, the standard socket that lets a language model query those tools directly. The aggregate is roughly 2.9 million (repository, library) rows, refreshed daily. None of that is the point. The point is the question it now answers.
So consider what the map makes answerable. Ask which government services depend on express, the most common web framework on npm, the public registry these services draw most of their open-source code from, and the answer is 1,830. Not a hope. A number. The reassurance that someone has solved your problem before stops being a feeling and becomes a query you can run.
It also lets reuse, long preached, finally be counted. Service Standard point 12 has said for years that public code is built with public money and should be reusable to avoid duplication. The GOV.UK Design System is the flagship proof: code reused over 3,300 times, downloaded over 2.7 million times, now used by more than 1,200 services, and on its lead's own estimate worth around £22m of benefit a year. That was always a claim resting on download counts. With the map, the dependency on govuk-frontend is visible service by service, so the value stops being asserted and starts being shown.
The map also tells a new team which ground is solid. Ask it for the most-depended-on packages and you get the unglamorous foundations every team quietly stands on, the debug, ms and semver of the world. That is not trivia. It is the difference between choosing a component and choosing a constraint you will live with for years, and it points a team toward the path that is well-trodden and well-supported rather than the one they will be maintaining alone.
And then there is the figure I find hardest to read as a mere statistic. Point one tool at two services and it measures how much of their ingredients they share: govuk-frontend and whitehall overlap by 19.2%. An overlap like that is not a metric. It is a collaborator the map has just introduced you to, a person to talk to and a shared component waiting to be lifted out and used by both, rather than maintained twice by two teams who never knew they were neighbours.
There is one honest limit worth naming. The map sees the direct ingredients each service declares, not yet the full tree of dependencies beneath them. That boundary is the tool's, not the idea's, and it is the next thing to extend.
The objection people reach for first is whether publishing your ingredients quietly arms an attacker. It does not: hiding a weakness does not remove it, and security through obscurity only removes your own ability to find the weakness before someone else does. The same property runs in reverse. When a flaw lands in a widely used package, the organisations that know their ingredients can find their exposure in hours; wire the aggregate map to a live vulnerability feed and the whole estate can find its exposure at once. Reuse and resilience turn out to be the same map read in two directions: who can I build on, and where does a problem reach.
That is the real category shift. An inventory tells you what you are made of. A map tells you what you can build next, and who is already building it alongside you. The bill of materials was always hiding inside the software; coding in the open is what let us stack the labels on a single gauge and turn a record kept for the regulators into the most practical reuse tool the public sector has. The point of all of it is a quieter one. Nobody in public service should have to start from a blank page alone, and now, the first move when a team opens that page is not to guess. It is to ask the map who is already there.
(Views in this article are my own.)