What this does not do

Every number on this page was measured, and each one is a limit rather than a feature. A tool that only publishes what it is good at is asking to be taken on trust, and this one is asking to be checked.

What the files actually contain

94.8% of components carry a package URL. 5.1% name a supplier.

5,088 components across 21 real SBOMs

The first number is higher than this project assumed before measuring, and it is stated first for that reason. Package URLs are largely present. What is missing is everything else: supplier is an NTIA minimum element and appears on 5.1% of components, and CPE, the identifier most published advisory data was matched on, appears on 40.9%.

A component with neither a purl nor a CPE is invisible to every advisory database. No vulnerability tool can say anything true about it, including this one. That is a property of the files the industry produces rather than of any checker.

Element by element

Element	Present	Share
Package URL	4,821	94.8%
CPE	2,079	40.9%
Version	5,011	98.5%
Supplier	260	5.1%
License	1,057	20.8%
Hash	1,696	33.3%

13 of 21 files carry a dependency graph at all, and 0 declare that graph incomplete. A file that is silent about its own completeness is the common case, not the exception.

The corpus is 21 files. 18 of them record the tool that produced them, naming 13 distinct generator versions; 3 record nothing. It is a sample, and a small one. Treat these as the shape of the problem rather than as industry figures.

This resolver declines to answer most of the time

It abstains on 92.2% of benchmark rows

When it does answer, it is right 100.0% of the time, and it assigns an identifier to 0 of the 250 unknown-class rows, 36 of which are real components carrying no identifier and the rest names from which none can be recovered. Those three numbers are one decision: a wrong identifier produces a confident clean verdict on a component nobody identified, and an abstention produces a gap somebody can see. The full table, including the baselines that beat us on F1, is on the benchmark page.

What a passing check does not mean

Not a regulatory opinion: No regulator has reviewed this tool. A rule pack is one reading of a published document, written down so you can disagree with it in specific places.
Not a submission outcome: Clearing every rule does not mean a submission will be accepted. The rules check what a document states, not whether what it states is true.
Not a vulnerability report: The free checker matches nothing against advisory sources. It reads your file against a rule pack and stops there.
Not a claim your file is complete: A rule can only see what is present. A component omitted from the file entirely is invisible to every rule in every pack, and no checker can tell you what is missing from a list it was handed.

Where the numbers come from

Coverage is scripts/coverage.py over 21 SBOMs, with its counting rules stated in its own docstring; NOASSERTION and NONE are not counted as values, which is what keeps the supplier figure at 5.1% rather than the much higher number a non-empty check produces. It is re-checked by scripts/coverage.py --check inside ./verify.sh, which fails the build if it stops reproducing.

The resolver figures come from bench/identity/published.json, produced by scripts/bench-publish.py and re-checked by the same script in the CI build job and in pnpm ci. Not in ./verify.sh: scoring the resolver needs built TypeScript and that script gates the build. This sentence used to say verify.sh checked both, which was not true of either half, on the page named for not doing that.

Measured 2026-09-20 against the corpus in fixtures/corpus. The date comes from the file scripts/coverage.py writes, not from this sentence. These are numbers about a sample of real files, not about yours.