Report both numbers. Total open vulnerabilities shows the size of the inventory. The reachable subset, meaning findings where your code can actually call the vulnerable function, shows where to work first. Show the reachable count as a priority filter on the total, never as a replacement for it.
What reachable means
Reachability analysis asks whether the vulnerable code in a dependency can be executed from your application. A library may be installed, with a CVE in one of its functions, while your code never calls that function. The finding is real in the sense that the package is present. It is less urgent than a finding in a function you call on every request.
Reachable is a statement about code paths, not about exploitability in your environment. Network exposure, authentication, and configuration still matter. So treat it as one input.
Why executives need both
If you report only the total, the number is large, rarely falls, and invites the question "why can't you just fix it all?" If you report only the reachable count, someone will ask what you are not showing, and a wrong analysis becomes a hidden blind spot.
| View | Strength | Risk |
|---|---|---|
| Total open | Complete, simple to audit | Overwhelming, hides priority |
| Reachable open | Focuses effort | Depends on analysis quality |
| Unknown reachability | Honest about gaps | Can look like noise |
Add a third bucket, "not analyzed", so that missing data is visible. A finding without reachability data must not be silently counted as unreachable.
How to set it up
- Run dependency scanning and reachability analysis on each service.
- Tag every finding as reachable, not reachable, or not analyzed.
- Keep unreachable findings open with a lower priority and a review date. They can become reachable when code changes.
- Report counts for each bucket, plus the trend of the reachable bucket.
- Re-run analysis after significant code changes, since reachability moves.
Rules that keep it honest
- Never auto close a finding because it is unreachable. Lower the priority and keep a record.
- Always fix known exploited vulnerabilities regardless of reachability until you have verified the claim.
- State the languages and ecosystems where the analysis is supported, since coverage varies.
- Spot check a sample by hand each quarter and report the agreement.
Presenting it
A single bar split into three colors works well, with one sentence: "Of 1,200 open findings, a small share is reachable, and those are in the plan for this quarter." Use real numbers from your own data when you present it.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the full list with the reachable view and notice which findings stay on top.
Quick check
Can an unreachable finding become reachable later?
Yes. A code change that starts calling the affected function turns it reachable. That is why unreachable findings stay open with a review date.
Does reachable mean exploitable?
No. It means the vulnerable code can be executed from your code. Exposure and configuration decide whether an attacker can use it.
Last reviewed: 19 October 2026.
