Software bills of materials have been mandated, regulated, and exchanged for five years, and they are still mostly useless in operation. Engineering teams generate them because a procurement contract or a federal directive requires it. Security teams receive them, file them in a storage bucket, and go back to the scanner. Meanwhile, the promise — that SBOMs would enable transparent, queryable, auditable software supply chains — remains largely unrealized.
My thesis is that SBOMs failed to deliver because the industry treated them as documents instead of products. A document is finished when it is written. A product is never finished — it evolves, it has users, it gets measured, and its quality is a function of how well it serves those users. Until we treat the SBOM ecosystem the way we treat any other engineering deliverable, the mandate will continue to produce paperwork and not safety.
What Does It Mean to Treat an SBOM as a Product?
A product has users with problems. It has acceptance criteria beyond "exists." It has a feedback loop: users find issues, maintainers fix them, quality improves over time. It is versioned, distributed, and observable.
A compliance-grade SBOM has none of these properties. It is generated once per release, shipped as a static file, and never looked at again unless a regulator or customer asks. When it contains errors — missing transitive dependencies, incorrect versions, unresolved components — no one notices, because no one is using it for anything that would surface the error.
Treating an SBOM as a product means starting from the question: who needs this, for what decision, and how will we know if it is good enough for that decision? The answers reveal that the document-style SBOM is insufficient almost everywhere it is claimed to be useful.
Who Actually Uses SBOMs, and What Do They Need?
There are roughly four user classes, and their needs diverge sharply.
The first class is the vulnerability analyst. They need an SBOM they can query against a CVE feed to determine whether a disclosed issue affects a given service. For this, the SBOM must be accurate about transitive versions and component identity. Most compliance-generated SBOMs fail on both counts — they capture direct dependencies well and miss or misattribute transitives.
The second class is the incident responder. When a Log4j-class event happens at 9 PM, the responder needs to know, within minutes, every deployed artifact that includes the affected component. This is an indexing and query problem, not a document problem. A pile of SBOM files in a bucket is the wrong data structure.
The third class is the procurement or risk team. They need to evaluate a vendor's software before it enters the organization. For them, an SBOM is useful only if it is trustworthy — signed, dated, and generated from a known-good build process. Unsigned SBOMs are often ignored, because they can be edited or fabricated trivially.
The fourth class is the regulator. They typically want evidence that an SBOM exists and was provided. This is the easiest user to satisfy and the least valuable. Optimizing for this user, which most programs do, produces compliance theater.
A program that takes SBOMs seriously builds for the first three users. The fourth gets satisfied as a side effect.
Why Do Most SBOMs Fail in Practice?
Because they are generated from the wrong source of truth. The common pattern is to run a generator against a package manifest — package.json, pom.xml, requirements.txt — and call the output an SBOM. This produces a declared dependency list, not an observed one. The declared list often diverges from the actual runtime bundle in ways that matter: vendored libraries, statically linked binaries, dependencies pulled in by build plugins, container base image contents.
A better SBOM is generated from the build artifact itself, not from the manifest. Tools that inspect container images, JAR files, or compiled binaries and enumerate what is actually inside produce SBOMs that match reality. This is more expensive and more reliable, and it exposes problems the manifest-based approach hides.
SBOMs also fail because they are generated once and never updated. A service in production today is not the same service that was shipped last quarter — dependencies may have been patched, base images may have been rebuilt, configuration may have changed. A static SBOM goes stale the moment it is written. Treating the SBOM as a live document, regenerated on every build and linked to the deployment, is the fix.
What Should SBOMs Look Like in an Operational System?
Operational SBOMs share several characteristics that compliance SBOMs typically do not.
They are queryable. Engineers and security teams can ask questions like "which services include log4j 2.x" and get an answer in seconds, not hours. This requires indexing every SBOM into a searchable store, not filing them as opaque JSON.
They are versioned alongside artifacts. Every container image, every binary, every deployable unit has a corresponding SBOM, and that relationship is discoverable. The naming and storage conventions matter — if you cannot go from a running pod to its SBOM in one lookup, the data is not operational.
They are signed and their signatures are verified. An SBOM without provenance is a suggestion, not evidence. Sigstore, in-toto attestations, and signed SPDX or CycloneDX documents give you something a regulator and a responder can both rely on.
They include VEX context. Vulnerability Exploitability eXchange statements let vendors say "yes we include this component, no it is not exploitable in our use." Without VEX, every SBOM that includes a vulnerable component triggers downstream alarms. With it, the signal-to-noise ratio collapses to something usable.
They are diffable. The ability to see what changed between two versions of an SBOM — which components were added, removed, upgraded, or swapped — is what makes the artifact useful for change review, supply chain auditing, and regression investigation.
Are CycloneDX and SPDX Good Enough?
They are good enough, and the industry should stop litigating the format war. Both formats support the operational properties above. The interoperability problems that remain are tractable — converters exist, tooling is maturing, and the cost of picking one and moving on is lower than the cost of continued debate.
The more interesting format gaps are in the adjacent space: VEX format consolidation, build attestation standards, AI-bill-of-materials (AIBOM) for models and datasets. These are where format choices still have real consequences, and where engineering leadership should be paying attention.
What Should a Mature SBOM Program Measure?
Not SBOM coverage. Coverage is a precondition, not a goal. A program at 100 percent coverage that cannot answer a useful question is worse than one at 60 percent with a working query layer.
The metrics that matter are response time (how fast can we find every affected artifact when a CVE drops), accuracy (what percentage of SBOMs match their artifacts when audited), freshness (how many SBOMs in production are within 24 hours of their build), and adoption (how many internal users query the SBOM store in a given month).
If no one is querying the SBOM store, no one is getting value from it, regardless of coverage numbers.
How Safeguard.sh Helps
Safeguard.sh treats SBOM generation, storage, and query as a first-class product surface. The platform generates SBOMs from build artifacts rather than manifests, signs them with verifiable provenance, and indexes them into a queryable store that engineers and responders can use in real time. VEX assertions are first-class, so the noise floor in vulnerability correlation stays manageable. When a new CVE lands, Safeguard.sh can tell you in seconds which deployed services are affected, which are exploitable given runtime context, and what the remediation plan looks like. The SBOM stops being a file you produce for someone else and becomes infrastructure you actually use.