Generating a software bill of materials is a solved problem. Add a step to the pipeline, get a file per build, tick the requirement.
The test of whether it was worth doing comes later, on the morning a serious vulnerability is announced in a widely used library and someone asks which of your services are affected. Most SBOM programmes cannot answer that question, despite having generated thousands of the things.
Why the artefact alone is not enough
An SBOM describes one build. The question you need answered is about what is running, right now, across the estate. Three things stand between those:
- You need to know which build is deployed where, at this moment, not which builds exist.
- You need the SBOMs queryable together, not sitting as files in a bucket beside their artefacts.
- You need transitive dependencies, because the library that matters is usually three levels down and nobody declared it.
Miss any one and you are back to asking teams to check, which is the process the SBOM was supposed to replace.
Make deployment the linking step
The connection that makes this work is between a running workload and the bill of materials for the exact image it is running. Where delivery is declarative and images are referenced by digest rather than by a moving tag, that link is already there to be used.
An SBOM you cannot connect to a running workload is an inventory of things that were once built.
This is a good argument against mutable tags for anything reaching production. A tag that moves means the SBOM you have on file may describe something other than what is currently running, and you will not find out until the answer matters.
Signing and provenance answer the other question
The bill of materials tells you what is inside an artefact. Signing and provenance tell you whether the artefact is the one your pipeline produced.
Both are needed and they answer different questions. Composition without provenance means you know what was supposed to be in there. Provenance without composition means you know it came from your pipeline but not what it contains.
Enforcement is what makes provenance real: admission control that refuses unsigned images or images without acceptable provenance. Generating attestations that nothing verifies is the same category of mistake as generating SBOMs that nothing queries.
Rehearse the query before you need it
The practice that separates a working programme from a compliant one is periodically running the question. Pick a library you use, ask which running services include it and at what version, and time how long the answer takes.
Do it when nothing is on fire. If it takes a day, it will take longer during an actual disclosure, when the answer is wanted urgently and by people who will keep asking for updates.
The bar to aim for
You should be able to name a package and version and get back the list of currently running services that contain it, in minutes, without asking a team to check. Anything short of that is an artefact you generate to satisfy a requirement rather than a capability you have.
