What is Reachability Analysis?

Definition

Reachability analysis is a technique used in static analysis and software composition analysis to determine whether a potentially vulnerable code path or function can actually be reached during the execution of a program. Rather than flagging every dependency with a known CVE, reachability analysis checks whether the vulnerable function in that dependency is called — directly or transitively — by the application.

The motivation is precision. A dependency may have a critical CVE in a function that your application never calls. Without reachability analysis, that CVE appears as a critical finding. With reachability analysis, the scanner can determine that the vulnerable function is unreachable and either suppress the finding or deprioritize it.

The False Positive Problem It Solves

Modern applications have deep, complex dependency trees. A Node.js application might have 500–1,000 transitive dependencies. CVE scanners that check every dependency version against vulnerability databases regularly produce hundreds of findings — many of which are not exploitable because the vulnerable code path is never reached.

Alert fatigue from unreachable CVEs is a real operational problem: security teams spend significant time triaging findings that are theoretically present but practically unexploitable. Reachability analysis filters this noise.

How Reachability Analysis Works

1. Build a call graph — map all function calls in the application code, including calls into libraries
2. Identify vulnerable functions — using CVE data, determine which specific functions in dependencies contain vulnerabilities
3. Trace paths — determine whether any execution path from an application entry point (HTTP handler, CLI command, scheduled job) can reach the vulnerable function
4. Report — findings are classified as reachable (potentially exploitable) or unreachable (theoretical only)

Reachability in SCA vs. SAST

Reachability analysis is applied in two contexts:

SCA reachability

Checking whether the vulnerable function in a third-party dependency is called by the application. Tools like Snyk, Socket, and Semgrep apply this to dependency CVEs, significantly reducing noise for SCA findings.

SAST reachability

Checking whether a potentially vulnerable code pattern can be reached with untrusted input from an entry point. This is closely related to taint analysis — reachability determines whether the path exists; taint analysis determines whether dangerous data can travel it.

Limitations

• Call graph construction is approximate — dynamic dispatch, reflection, and metaprogramming can cause the call graph to miss paths that exist at runtime
• Language-specific accuracy — call graph accuracy varies significantly by language; statically typed compiled languages are more accurate than dynamic languages
• Entry point completeness — if the analysis misses an entry point, it may mark reachable paths as unreachable

Reachability and Autonomous Code Governance

Reachability analysis is a precision multiplier for autonomous code governance. Rather than generating fixes for every theoretical vulnerability, an autonomous system can prioritize findings where the vulnerable path is confirmed reachable — the highest-value, highest-confidence subset of all findings.

Hydra incorporates reachability analysis into its prioritization model, ensuring that autonomous remediation effort is directed at vulnerabilities that represent real risk rather than theoretical exposure in unused code paths.