Report reachable vulnerabilities next to the total, not instead of it. Show how many findings exist, how many sit in code paths your application can actually call, and how you decided. Keep unreachable items visible and tracked so the filter never becomes a way to make a number look better.
Why reachability belongs in a report
A dependency scan may list hundreds of vulnerable components, yet many affect functions your code never calls. Reachability analysis checks whether a vulnerable function can be reached from your code. It cuts noise for engineers, and it gives leaders a more truthful picture of near term risk.
It also carries a risk: if the report shows only the reachable number, a reader may believe the rest does not exist.
The two-line pattern
| Line | Meaning |
|---|---|
| Total findings | Everything matched in your components |
| Reachable findings | Subset with a call path from your code |
| Not reachable, tracked | Subset parked with a reason and review date |
| Unknown | Subset the analysis could not determine |
The fourth row matters. Static analysis cannot always resolve dynamic calls, reflection or generated code. Report "unknown" honestly rather than folding it into "not reachable".
Steps
- Run dependency scanning and reachability on the same build.
- Label each finding reachable, not reachable or unknown.
- Set remediation targets by reachable severity, with a longer, documented target for the rest.
- Keep not reachable items in the backlog with a review date, because code changes can make them reachable.
- Re-run on every release and on new advisories.
State your method
Add a footnote: tool and version, languages covered, languages not covered, and date of the run. A reader should know the claim covers, for example, only Java and Python services.
Watch for
- Findings that become reachable after a refactor. Treat a change in label as an event.
- Transitive dependencies, where the call path runs through another library.
- Pressure to hide the total. Resist it, because auditors and customers ask for totals.
Try it yourself
Open the demo and compare the list before and after the reachability filter. Notice which items remain and which are set aside.
Click through it at your own pace, or open it full screen.
Safeguard provides reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Can we stop tracking unreachable findings?
No. Keep them with a review date, since a code change can make them reachable.
What does "unknown" mean?
The analysis could not decide, for example because of dynamic calls. Report it separately.
Last reviewed: 19 October 2026.
