Reachability analysis checks whether your application can actually call the vulnerable function in a dependency. In a zero-day it helps you rank which systems to fix first. It should not be used to declare a system safe on its own, because the code, the configuration and the attacker's options can change.
What reachability tells you
A dependency may contain a flaw in a function your code never calls. Static analysis follows call paths from your entry points into the library. If no path reaches the vulnerable function, the flaw is less likely to be exploitable in your application as built.
What it does not tell you
| Limit | Why it matters |
|---|---|
| Dynamic behavior | Reflection, plugins and configuration can create paths a static check misses |
| Future changes | A later commit may begin calling the function |
| Other consumers | A different team may use the same library differently |
| Not the same as patched | The flaw is still present |
For these reasons, keep the flaw on the list and rank it lower, rather than removing it.
A triage order
- Internet-facing, reachable, exploitation reported: first.
- Internet-facing, reachable, no reported exploitation: next.
- Internal, reachable: after the above.
- Not reachable: schedule with normal updates and record the reasoning.
Record why you marked something not reachable. An auditor, a customer or your future self may ask. Consider a structured statement such as a VEX entry; see VEX not affected justifications for unreachable code.
Combine with exposure and exploitation
Reachability is one signal. Pair it with whether the system is exposed to untrusted networks and whether exploitation is reported. Reachability versus EPSS versus KEV versus CVSS compares how the signals complement each other.
Example
A web service imports a parsing library but only calls its safe functions. A flaw is reported in a function the service never calls. The finding is lower priority, yet it stays on the list with a note, and the library is updated in the next normal cycle.
Try it yourself
Click through it at your own pace, or open it full screen.
Check how a finding's priority changes once exploitability is considered.
Where Safeguard fits
Safeguard includes reachability analysis alongside SBOM and dependency scanning, so you can rank findings by whether vulnerable code is called. A free scan shows how it looks on a real repository.
Quick check
If code is unreachable, can we skip the update?
Not forever. Rank it lower, record the reasoning, and update with the normal cycle.
Does reachability replace the exposure check?
No. Use both. A reachable flaw on an internet-facing system is the top priority.
Last reviewed: 19 October 2026.
