Reachability Analysis

How Reachability Analysis Works

A reachability tool builds a call graph of the application. It starts at entry points such as HTTP handlers, CLI commands, message consumers and scheduled jobs, then traces whether any path leads to the vulnerable function. Results usually fall into one of four levels of precision.

• Package level. Is the vulnerable dependency installed at all?
• Import level. Is the package imported anywhere in the codebase?
• Function level. Is the specific vulnerable function called on a path from an entry point?
• Data-flow level. Does attacker-controlled input actually reach that function?

Package-level checks only confirm that a vulnerable version is present. Function-level and data-flow analysis are what let a team say "this CVE is installed, but nothing in our code can trigger it."

Why Reachability Matters for Vulnerability Triage

Dependency scanners typically report every known CVE in every installed package, including transitive ones. Many of those vulnerable functions are never called. Without reachability, engineers spend time investigating issues that could never be triggered, which feeds alert fatigue and erodes trust in security tooling.

Reachability gives triage a defensible way to lower the priority of findings that are present but not callable, so effort goes to the ones that are.

Reachability vs Exploitability

The two are often confused, and a reachable finding is not automatically exploitable. Reachability asks whether the vulnerable code can run, using the call graph, entry points and dependency tree. Exploitability asks whether an attacker can actually abuse it, which depends on attacker-controlled input, configuration and existing mitigations. Reachability produces "reachable", "not reachable" or "unknown", while exploitability is best answered with a validated exploit or proof of impact.

Both signals feed priority alongside business context. Exploit validation covers the second half of the question.

Limitations of Reachability Analysis

• Dynamic behavior. Reflection, dynamic imports and dependency injection can hide call paths from static analysis.
• Unknown entry points. Code invoked by frameworks, plugins or infrastructure may not appear in the graph.
• Unknown is not unreachable. Good tools report "unknown" when they can't decide, rather than suppressing the finding.
• Results go stale. A new code path can make a dormant vulnerability reachable, so analysis has to rerun as code changes.

How Nullify Uses Reachability Analysis

Nullify scores every finding on reachability, exploitability, business context and confidence before a human sees it. Noise such as unreachable code and test fixtures is filtered out, and findings are re-triaged automatically when code, dependencies or threat intelligence change. Learn how Nullify handles triage and remediation.