A bad SBOM is worse than none: why document quality matters

As SBOMs have shifted from novelty to requirement, a quiet problem has emerged: most SBOMs are not very good. They are generated to satisfy a checkbox, they are missing critical fields, and they create a false sense of security precisely because they exist. It is worth saying plainly: a bad SBOM can be worse than no SBOM at all, because it manufactures confidence without delivering visibility. The fix is to treat SBOM quality as something you measure, not assume.

The compliance-theater trap

When a regulation or a customer demands an SBOM, the path of least resistance is to generate something — anything — that can be attached to an email and called done. The result is a document that technically exists and substantively fails:

• Components with no version, which makes vulnerability matching impossible.
• A flat list of direct dependencies with the transitive graph missing.
• No unique identifiers, so components cannot be reliably matched to advisories.
• No license data, no hashes, no supplier information.

A document like this passes a superficial "do you have an SBOM?" check while being useless for the thing SBOMs are actually for. Worse, it lets everyone believe the box is checked.

What "quality" actually means

A high-quality SBOM is one that can do its job: let you identify every component, match it against vulnerabilities, understand its relationships, and account for its license and integrity. Concretely, quality comes down to completeness across several dimensions:

1. Identifiers — does every component have a machine-readable ID (PURL or CPE)?
2. Versions — does every component have a precise version? This is the single most important field for security use.
3. Relationships — is the dependency graph present, including transitive dependencies, or just a flat list?
4. Licenses — is license information captured for governance?
5. Integrity — are cryptographic hashes present so components can be verified?
6. Metadata — is there supplier information, a timestamp, and a recorded author?

An SBOM strong on all of these is an asset. One missing versions and relationships is, for practical purposes, a list of names.

Measuring it: the quality score

Because quality is multi-dimensional, it lends itself to scoring. The idea behind an SBOM quality score — including our own — is to grade a document against these dimensions and produce a single, comparable measure (a 0-to-100 score, or an A-to-F grade) plus concrete guidance on what is missing.

A score does two useful things. It turns a vague worry ("is this SBOM any good?") into a number you can track and improve, and it gives you a gate: you can require that SBOMs meet a quality bar before they are shared with customers or filed as compliance evidence, the same way you gate on test coverage or build success.

Quality is a process problem, not a one-time cleanup

The reason most SBOMs are low quality is rarely that the data is unavailable — it is that nobody is checking. The remedy is to make quality measurement part of the pipeline that produces SBOMs in the first place:

1. Generate the SBOM automatically from the build, so it reflects reality.
2. Score it as part of the same process.
3. Surface what is missing, with specific fixes.
4. Re-score on the next release, so quality trends up over time instead of decaying.

The era of "do you have an SBOM?" is ending; the era of "is your SBOM any good?" has begun. The teams that win are the ones who stopped treating the SBOM as a document to produce and started treating it as a data asset to be measured, graded, and continuously improved.