No count is right. A low number can mean a clean repo or a blind scanner, and a high number can mean real risk or heavy duplication. Instead of judging the total, run three checks: compare with a known repo, count unique packages, and review a sample of findings by hand.
Why the total misleads
Both ends of the range can be wrong:
- Low count. The repo might be well maintained. Or the scan might have skipped files, lacked a lockfile, or used stale advisory data.
- High count. The repo might hold old dependencies. Or the tool might list every occurrence separately, include dev tooling, or ignore context that would lower urgency.
Without a way to tell which case you are in, the number is decoration.
Three sanity checks
- Known repo check. Scan the repository where you already know several real issues. If the tool misses them, a low count elsewhere is suspect.
- Unique package check. Group findings by package. Divide the total by the number of unique packages. A ratio far above one suggests the same issue listed many times.
- Hand review of ten. Choose ten findings across severities, including a few from the middle. For each, ask: is the package actually present, is the version within the affected range, and is it used in production?
Record how many of the ten were correct and relevant. That gives you a rough precision for your repo, from your own review.
Turning the sample into a statement
| Of ten reviewed | Reading |
|---|---|
| Nearly all correct and relevant | Output is trustworthy for this repo |
| Correct but mostly irrelevant | Accurate matching, weak prioritization |
| Several incorrect | Matching problems; examine versions and ecosystems |
Ten findings is a small sample. Treat the result as a signal, not a statistic, and repeat on another repo before drawing a firm conclusion.
What helps reduce the count honestly
Some reductions are legitimate. Not counting a vulnerable function your code never calls is a defensible way to prioritize, as long as the evidence is visible. Grouping duplicates is another. Hiding findings with no explanation is not.
Ask the demo to show what is hidden and why. The ability to see the full list, and to see which filters are applied, is more important than a small headline.
What to expect about backlog
If your repo is old, the first scan often finds a lot of existing debt. That is normal. The practical question is how the tool helps you separate new problems from the old backlog, and how it supports working the backlog down in a sensible order.
Set expectations with your team before the demo. A large first number is a starting point, not a verdict on anyone.
Where Safeguard fits
Safeguard combines dependency scanning with reachability analysis, so you can look at findings both before and after that filter. The demo below shows the effect on a list.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the numbers before and after, and ask what evidence supports each removed finding.
Quick check
Is zero findings a good result?
Only if coverage was complete and the data was current. Check files read and advisory freshness first.
Is ten findings enough to judge accuracy?
It is enough for a signal. Repeat on a second repository before deciding.
Last reviewed: 19 October 2026.
