When a serious vulnerability is disclosed in a widely used library, the first question every engineering organization asks is whether they are affected. Teams without an inventory spend days finding out — grepping repositories, asking around, checking builds one at a time. Teams with a working software bill of materials answer in minutes.
That is the entire value proposition, and it explains why most SBOM programmes fail: they generate the documents and never build the ability to query them.
What changed in 2026
- Procurement requirements spread. More buyers, particularly in regulated sectors and government supply chains, began requiring SBOMs as a contractual condition rather than a nice-to-have.
- Provenance overtook inventory in importance. Attesting that an artifact was produced by a specific build from specific source proved more valuable than listing contents alone.
- Tooling consolidated around two formats. Interoperability between the main SBOM standards improved enough that format choice stopped being a strategic decision.
- Signing became routine. Keyless signing tied to build identity moved into standard pipeline templates rather than requiring bespoke key management.
Generating something useful
| Approach |
Accuracy |
Notes |
| Scan the source repository |
Poor |
Misses transitive and build-injected dependencies |
| Parse the lockfile |
Better |
Misses system packages and vendored code |
| Generate during the build |
Good |
The build knows what it actually pulled |
| Analyze the final artifact |
Best for containers |
Catches base image contents too |
| Combination of build plus artifact |
Most complete |
What mature pipelines do |
Build-time generation is the minimum bar. A source scan tells you what the manifests declare, which is not the same as what the build produced — resolution differences, platform-specific dependencies, and build-time code generation all create gaps. For containers, scanning the final image catches everything the base layer contributed, which is frequently more than the application's own dependencies.
The part that gets skipped
Generating SBOMs is easy and adds a step to a pipeline. Making them useful requires three additional things that most programmes never build.
Storage keyed to deployment. An SBOM sitting in a build artifact nobody can find is not an inventory. You need to know which SBOM corresponds to what is running in production right now, which means associating them with deployed versions rather than with builds.
A query path. On disclosure day the question is which of our running services contains this package at a vulnerable version. Answering that requires the SBOMs to be searchable across your whole fleet, not stored individually.
A drill. Run the query before you need it. Pick a package at random and ask where it runs. Teams discover their SBOM programme does not work during a real incident, which is the worst time.
Provenance is the more valuable second half. Signed attestation proving an artifact came from a specific commit through a specific build removes the class of attack where a legitimate-looking artifact was produced somewhere else entirely. Verifying signatures at deploy time is where the inventory becomes an actual control rather than a document — and it belongs in the pipeline alongside the caching work in CI/CD caching strategies.
Common mistakes
- Generating from source instead of the build. Incomplete in ways that matter precisely when it matters.
- Storing SBOMs with no query capability. Compliance artifacts rather than security tooling.
- Ignoring base image contents. For containers, the base frequently contributes most of the inventory.
- No signature verification at deploy. Provenance you generate and never check is provenance you do not have.
- Treating it as a one-time project. Dependencies change every build; the inventory has to keep pace.
FAQ
Which format should I use?
Either major standard is fine and tooling converts between them. Pick what your consumers ask for and move on; this is not the decision that determines success.
Does an SBOM improve security by itself?
No. It improves response time, which reduces exposure window. The control is the response capability it enables.
Should SBOMs be public?
For open source, commonly yes. For commercial software, usually shared under agreement with customers who ask. There is no general obligation to publish.
What about transitive dependencies?
They must be included — most vulnerabilities arrive transitively, and an SBOM listing only direct dependencies misses the majority of your actual surface.
Where to go next
For pipeline structure, read CI/CD caching strategies. For runtime authorization concerns, OAuth 2.1 explained, and for AI-specific supply chain risk, MCP security risks.