If a security tool trial reports thousands of findings, do not read the number as value or as noise until you sample it. Group findings by cause, review a random sample of about 50, measure the share that is real and reachable, and judge the tool on that share, not on the total.
A big number proves little
A tool that flags everything looks thorough on day one and exhausting on day ten. A tool that flags a hundred well chosen items may be far more useful. What matters is how many findings a developer would act on and how fast the team can tell.
Step 1: group before you judge
Most large totals collapse when grouped. Typical groupings:
- By root cause: one outdated library may account for hundreds of entries.
- By fix: one version bump may clear dozens of findings.
- By location: test code, examples and vendored folders behave differently from production services.
- By duplicate: the same issue reported under several identifiers.
Record the count before and after grouping. The "after" number is the one a human has to face.
Step 2: sample randomly
Pull a random sample of about 50 findings. Do not hand pick. Triage each as:
| Verdict | Meaning |
|---|---|
| True and reachable | Real issue and the vulnerable code is used |
| True, not reachable | Real component issue, but the affected code path is not called |
| False positive | The tool is wrong |
| Duplicate | Already counted |
| Unclear | Needs more information |
Fifty items is a small sample, so treat the percentages as rough. If 5 of 50 are reachable, you are looking at roughly a tenth of the total as urgent. That is a planning figure, not a statistic to publish.
Step 3: check the prioritisation
Does the tool help you choose what to fix first? Look for signals such as reachability, known exploitation, fix availability and the severity in your context. If everything is labelled critical, the tool is not prioritising. See the reachability demo to see what a filtered view can look like.
Step 4: measure effort, not volume
Time how long each verdict took. If a typical finding needs eight minutes of research, a thousand findings is over a hundred hours. If the tool provides context and a suggested fix, that time drops. Effort per finding is a better metric than finding count.
Step 5: look at the fix path
For the true and reachable group, see how the tool helps you fix them. Does it show the safe version? Can it open a pull request? Does it show breaking changes? A big backlog with an easy fix path is manageable. A big backlog without one is a project.
What to tell leadership
Avoid reporting the raw total. Report something like: "The tool reported a large number of items. After grouping, the work reduced to a smaller set of root causes. In a random sample, roughly this share was reachable. The estimated fix effort is this many days." Include the sample size so nobody mistakes it for a precise rate.
Common mistakes
- Comparing totals between two tools. Counting rules differ.
- Treating scanner severity as the risk.
- Fixing in order of the list rather than by impact.
- Forgetting that the backlog existed before the tool. The tool did not create these issues, it exposed them.
Safeguard combines dependency scanning with reachability analysis, so a free scan is a quick way to compare a raw list with a reachable subset on your own project.
Try it yourself
Open the demo and compare the full list with the filtered one. Note how much shorter the working list becomes.
Click through it at your own pace, or open it full screen.
Quick check
How big should my sample be?
Around 50 random findings gives a rough picture. Larger samples help if the total is very large, but even 50 beats guessing.
Is a higher finding count a better tool?
Not by itself. Judge the share that is accurate, reachable and fixable, and the effort needed to triage each one.
Last reviewed: 19 October 2026.
