Yes, raw totals become incomparable. A scanner that lists every vulnerable package present and one that filters to findings whose vulnerable code is called answer different questions. Compare them on the same layer: present, then reachable, and keep both numbers labeled.
Two layers of the same problem
Presence asks whether a package with a known flaw is in your dependency tree. A version comparison against advisory data answers it.
Reachability asks whether your code can actually call the vulnerable function or path. It needs an analysis of how your code uses the library.
A report built on presence will list every match. A report built on reachability will list a subset, or will rank the reachable ones first. If you set the two side by side, one number looks small and the other large, and neither is wrong.
How to compare fairly
- Ask what layer each number is. Read the tool's documentation, or check one known case, such as a flaw in a function you never call.
- Get the presence list from both. Align scope and inputs so that this layer matches between tools. Present count differences then come from data, not from filtering.
- Get the reachable subset from each tool that offers it. If only one tool offers it, you cannot compare reachability across the two. Compare presence, and treat the reachability output as extra information.
- Validate a sample by hand. Pick a few findings marked unreachable and read the code. Pick a few marked reachable and confirm the call path.
- Record the limits. Reachability depends on language support and on how dynamic your code is. Reflection, plugins and generated code can hide a call path.
| Layer | Question | Strength | Limit |
|---|---|---|---|
| Presence | Is the package here? | Broad, simple to verify | Many matches never run |
| Reachable | Can our code call it? | Focuses effort | Depends on analysis coverage |
| Exploitable in context | Can an attacker use it here? | Closest to real risk | Needs environment knowledge |
Do not treat unreachable as safe forever
Code changes. A new feature can start calling the vulnerable function. Rerun the analysis on each build, not once. Keep unreachable findings in the register with their status, so a later change can flip them.
Also remember that other issues in the same package can be reachable even when one flaw is not. Review per advisory, not per package.
Using it for priority, not for exclusion
A sound use is ordering. Fix reachable findings with a fix available first. Schedule the rest. A weaker use is deleting the unreachable ones from view, which loses the evidence you will want when an auditor or customer asks how you decided.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the full list with the reachable view and note which findings drop out and why.
Where Safeguard fits
Safeguard includes reachability analysis alongside SBOM and dependency scanning, so a finding can be viewed on both layers. A free scan at gold.safeguard.sh/scan lets you compare it with your current tool on one project.
Quick check
If a tool reports fewer findings, is it missing things?
Not necessarily. It may be filtering by reachability. Compare the presence layer first.
Can reachability results change without a code change?
Yes, if the analysis improves or the dependency changes. Rerun it regularly.
Last reviewed: 19 October 2026.
