A coverage count such as "millions of packages indexed" measures how much data a vendor holds, not how accurately it protects your software. It says nothing about freshness, depth or the ecosystems you use. Ask what the count is a fraction of, how often it updates, and whether it matches your dependencies.
Size is not quality
Large numbers impress, and they are easy to produce. A database can grow by indexing every published version of every package, including abandoned ones, while still missing advisories for the ones you use. A smaller, well maintained dataset can serve your stack better.
Three different things hide inside a count:
- Packages indexed. Names the vendor knows exist.
- Advisories linked. Known issues tied to those names and version ranges.
- Analysis depth. Whether the vendor knows more than the name, such as which functions are affected.
A claim about the first says little about the second or third.
Questions about denominators
| Question | Why it matters |
|---|---|
| Out of how many packages that exist? | A count means more with a total |
| Which ecosystems make up the count? | Your languages may be a small share |
| How many entries have affected version ranges? | Without ranges, matching is guesswork |
| How many have function level data? | This drives reachability accuracy |
| How is the data sourced and checked? | Quality depends on process |
If the vendor cannot give a denominator, say so in your ledger.
Test coverage on your own stack
You do not need the vendor's numbers to measure what matters to you.
- Export the dependency list from three of your repositories.
- Choose ten packages across them, including a few obscure ones and a few from private or niche registries.
- For each, check whether the tool recognises the package and its version.
- Choose five public advisories for packages you use. See whether each appears, and whether the affected range is right.
- Note the packages the tool does not recognise. How does it say so?
An honest "unknown package" message beats a silent clean result.
Freshness is the other half
Ask how long new advisories take to appear, and whether old entries are corrected when maintainers revise them. A big database that updates weekly can lose to a smaller one that updates within hours. Measure this by watching a few new advisories over a week, as described in other posts on timing tests.
A fair way to compare two counts
When two vendors quote different totals, do not pick the larger. Normalise instead. Take your own list of ten packages and five advisories, and score each tool on how many it recognises correctly. A tool with a smaller headline number that gets all fifteen right serves you better than a larger one that misses three.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and zero-day discovery. Judge them on your own packages with the free scan at gold.safeguard.sh/scan, and compare the result with any headline count you read, from any vendor.
Quick check
Is a larger database always better?
No. What matters is accuracy for the packages you use, and how fresh the data is.
What is the simplest coverage test?
Take ten of your real packages and five known advisories, and check each against the tool.
Last reviewed: 19 October 2026.
