Zennoxa Shield
Application Security Glossary

Reachability Analysis

Reachability analysis is a technique that determines whether the vulnerable code inside a dependency or codebase can actually be invoked along an executable path from your application, so teams can distinguish exploitable flaws from ones that are present but never reached.

Reachability analysis asks a practical question about a vulnerability: can the vulnerable function actually be called from the running application? A project may depend on a library that contains a known flaw, but if the specific vulnerable function is never on any code path your app executes, the real risk is much lower.

Tools implement reachability by building a model of the program — such as a call graph or import/usage analysis — and checking whether there is a path from application entry points to the vulnerable code. Approaches range from lightweight symbol-and-import matching to deeper interprocedural call-graph tracing. Results are typically expressed as reachable, not reachable, or unknown when analysis is incomplete.

For developers, reachability is one of the highest-leverage ways to cut vulnerability noise. Confirming that a flaw is unreachable lets you safely defer it, while confirming reachability sharply raises priority. Because reachability requires code context and is not always decidable, it is used as one input among several rather than a sole gate.

Frequently asked questions

What is reachability analysis?
Reachability analysis determines whether a vulnerable piece of code can actually be reached and executed from your application. It helps separate vulnerabilities that are genuinely exploitable from ones that merely exist in unused code.
How does reachability analysis work?
It builds a model of the program — such as a call graph or usage map — and checks whether an executable path connects application entry points to the vulnerable function, reporting the finding as reachable, not reachable, or unknown.
Why does reachability reduce vulnerability noise?
Many reported vulnerabilities live in code your app never calls. Marking those as unreachable lets teams safely deprioritize them and concentrate on flaws that sit on real execution paths.

Related terms

Reachability Analysis — Zennoxa Glossary — Zennoxa Shield