Report both counts and label each one. The total shows how many known vulnerabilities exist in your components. The reachable count shows how many sit on code paths your application can actually execute. Showing only the smaller number risks hiding risk, and only the larger one hides signal.
Definitions
Total. Findings where a component version matches an advisory, regardless of how the component is used.
Reachable. The subset where analysis finds a call path from your code to the vulnerable function or behaviour.
Not reachable. The subset where analysis finds no such path. This is a statement about the analysis, within its limits, not a guarantee of safety.
Unknown. Findings where the analysis could not decide, because the language is unsupported, the function is not identified in the advisory, or dynamic behaviour defeats it.
Why the unknown group matters
Reports that show only reachable and not reachable tend to fold unknown into one of them. If unknown is folded into not reachable, you understate risk. If folded into reachable, you lose the benefit of the analysis. Keep the four groups separate on the page.
| Group | Meaning | Typical handling |
|---|---|---|
| Reachable | Path found | Prioritise |
| Unknown | Analysis inconclusive | Treat as potentially affecting, review by severity |
| Not reachable | No path found | Lower priority, recheck on code change |
| Total | All matches | Inventory view |
Rules for presenting
- Show the funnel from total to reachable on one chart, so readers see the reduction and the groups it came from.
- Keep the reachable figure next to the unknown figure.
- State the analysis coverage: the share of findings for which analysis was possible.
- Recompute when code changes, since a new import can make a dormant path live.
- Keep not reachable findings in the record. A refactor can wake them up, and some obligations require showing the full inventory.
Auditing the analysis
Pick ten findings marked not reachable and try to confirm by reading the code. Pick ten marked reachable and confirm the path. Record disagreements. A few misses are informative about where the analysis is weaker, such as reflection heavy code.
Do not replace other signals
Reachability is one input. Exploit evidence, such as listing in a known exploited catalog, should still raise priority even when the path is unknown. Configuration and environment also affect exposure in ways code analysis does not see. And vulnerabilities in components that handle untrusted input deserve attention even when a path is hard to prove.
Communicating to leaders
A sentence such as "of all known matches, a subset sit on paths our code can run, and we are fixing those first, while keeping the rest on a review schedule" is accurate and avoids false comfort.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Reachability analysis is part of the platform, and findings keep their total and reachable status side by side. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Does not reachable mean safe?
No. It means the analysis found no path within its limits. Recheck when code changes and keep the item on a review schedule.
What should I do with unknown results?
Keep them visible as their own group and prioritise by severity and exploit evidence until they are reviewed.
Last reviewed: 19 October 2026.
