Ask reachability first, because it is cheap and often answers the question: does your code call the vulnerable function at all? If not, urgency drops. If yes, ask exploitability: can an attacker supply the input and conditions needed to trigger it in your setup?
Definitions
Reachable: a path exists in your code from an entry point to the vulnerable function in a dependency.
Exploitable: the flaw can actually be triggered by an attacker in your environment, given configuration, inputs and surrounding controls.
Reachable does not guarantee exploitable. A function may be called only with values you control. Not reachable does not mean harmless forever, because code changes and a new call may be added later.
Why this order
Reachability analysis can be automated across a whole dependency tree, so it filters many findings quickly. Exploitability needs context and often a human, so spend that effort on what survives the first filter.
Triage table
| Reachable | Exploit conditions plausible | Suggested priority |
|---|---|---|
| Yes | Yes | Fix first |
| Yes | Unclear | Investigate, patch soon |
| Yes | No, documented reason | Schedule, record the reason |
| No | Not applicable | Low, but upgrade in normal cycles |
| Unknown | Unknown | Treat as reachable until shown otherwise |
Questions for exploitability
- Does attacker controlled data reach the affected function?
- Does the flaw need a non default setting that you have not turned on?
- Is the service exposed to the internet or only internal?
- Does a control in front, such as a filter or network rule, block the trigger?
- Is there a known public exploit or evidence of use? Check public lists of exploited vulnerabilities.
Record the decision
When you decide a finding is not exploitable, write why and when it should be rechecked. That note is what an auditor or customer wants to see, and it protects the next engineer from redoing the work.
Common mistakes
The usual error is treating reachability as a verdict and closing tickets in bulk. It is a filter. Keep a short review date on anything you downgrade, because an unrelated change can create a new call path. Another error is assuming that a failed analysis means not reachable. Tools differ in language coverage and in how they handle dynamic calls, so unknown should stay unknown. Tell auditors which languages your analysis covers and where it has limits.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability filtering.
Quick check
Can I ignore unreachable findings?
Deprioritize, not ignore. Code evolves, so keep them tracked and upgrade in routine cycles.
Is a high CVSS score enough to act?
It is one input. Combine it with reachability and exploit evidence.
Where Safeguard fits
Safeguard provides reachability analysis, SBOM and dependency scanning and policy gates. The free scan is a quick start.
Last reviewed: 19 October 2026.
