We generated SBOMs for a year before they did anything. They were JSON files in a bucket that a client asked for once. The supply-chain work that actually moved our risk was unglamorous and had little to do with the document itself. The SBOM is the receipt, not the security.
Generate it where you build, sign what you ship
An SBOM written by hand or after the fact is fiction. We generate it inside the build, from the same dependency graph the build uses, so it reflects what actually went into the artifact. Then we sign the artifact and the SBOM together, so that at deploy time we can refuse anything we did not build ourselves. That refusal is the control. The list of components is just evidence.
- Produce the SBOM in CI from the real build graph, not a separate scan
- Sign artifacts and verify signatures at admission, so unsigned images cannot deploy
- Pin dependencies by digest, not by tag that can be moved under you
- Fail the build on a new critical vulnerability in something you actually call, not in transitive code you never reach
Reachability is the difference between signal and noise
The first time we wired vulnerability data to our SBOMs, we got four hundred findings and the team learned to ignore the dashboard in a week. Most were in code paths we never execute. We now weight by whether the vulnerable function is reachable from our entry points. That cut the actionable list from four hundred to roughly a dozen, and people started fixing those dozen because they were real.
A scanner that cries about every transitive package teaches your team to ignore scanners. Triage for reachability or do not bother alerting.
The theatre to avoid
Theatre is generating a beautiful SBOM, attaching it to a release, and never querying it again. The test of whether yours is real: when the next widely-used library has a serious flaw, can you answer in five minutes which of your services ship it, and which versions? If that query takes a day of grepping repos, your SBOM is decoration.
What changed for us
When a popular logging library had its bad week, we answered the are-we-affected question for forty services in about ten minutes, because we could query our SBOM inventory. That was the entire point. Not the file. The ability to ask the file a question on the worst day and get a fast, true answer.