Category: Software Supply Chain
Reachability Analysis
Also known as: Vulnerability Reachability Analysis, Code Reachability Analysis
Simply put
Reachability analysis is a technique that determines whether specific code paths in an application or its dependencies can actually be reached during execution. It helps security teams focus on vulnerabilities that are genuinely exploitable in context, rather than all vulnerabilities present in a dependency. This reduces alert noise and helps prioritize remediation efforts.
Formal definition
Reachability analysis is a code analysis method used to evaluate whether vulnerable functions or code paths within an application or its third-party dependencies are invocable given the application's actual call graph and control flow. By integrating manifest, lockfile, and static analyses, tools can determine whether a known-vulnerable code path in a dependency is referenced and traversable from application code, distinguishing theoretically present vulnerabilities from those that are plausibly exploitable under the application's execution model. This approach typically operates at the static level, meaning it can identify whether a vulnerable symbol is referenced in code without requiring runtime execution context. Consequently, it may produce false positives where a reachable path is not exercisable at runtime due to dynamic conditions, and false negatives where runtime-only call patterns such as reflection or dynamic dispatch are not modeled. Scope boundaries include limitations around detecting vulnerabilities that require runtime or deployment context to assess true exploitability.
Why it matters
Most applications depend on dozens or hundreds of third-party libraries, and any given dependency may contain multiple known vulnerabilities. Without reachability analysis, security teams receive alerts for every vulnerability present in every dependency, regardless of whether the vulnerable code is ever invoked by the application. This produces significant alert fatigue and leads teams to spend remediation effort on vulnerabilities that pose no practical risk in their specific deployment context.
Who it's relevant to
Application Security Engineers
Application security engineers use reachability analysis to triage SCA findings and separate vulnerabilities that require immediate attention from those present in unused code paths. This allows them to build more defensible prioritization frameworks and reduce the volume of findings escalated to development teams.
Software Developers
Developers benefit from reachability analysis because it reduces the number of vulnerability alerts they receive that are not actionable given how they are actually using a dependency. This helps them focus remediation work, such as upgrades or patches, on libraries whose vulnerable functionality is genuinely invoked by their code.
Security Operations and Vulnerability Management Teams
Teams responsible for tracking and remediating vulnerabilities across a software portfolio can use reachability analysis to assign more accurate severity and urgency ratings. Rather than treating every CVE in a dependency as equally critical, they can distinguish between vulnerabilities in reachable code paths and those in code the application never calls.
Platform and DevSecOps Engineers
Engineers integrating security tooling into CI/CD pipelines use reachability analysis to gate builds or generate targeted alerts without creating excessive noise that causes developers to ignore security findings. Incorporating reachability context into pipeline checks helps maintain security coverage without significantly slowing development velocity.
Inside Reachability Analysis
Call Graph Construction
A mapping of function and method invocation relationships across the codebase, used to trace execution paths from entry points through application code and into dependencies. The precision of the call graph directly determines the accuracy of reachability conclusions.
Entry Point Identification
The process of defining where execution can begin, such as HTTP handlers, message queue consumers, CLI commands, or exported API methods. Reachability analysis is bounded by the completeness and accuracy of the defined entry points.
Vulnerable Code Path Mapping
The tracing of execution from identified entry points through application logic to determine whether a known-vulnerable function, method, or code block in a dependency can actually be invoked during normal or adversarial operation.
Static Approximation
The use of conservative or optimistic over-approximations to model program behavior without executing code. Static reachability analysis typically over-approximates to avoid false negatives, which can introduce false positives by flagging paths that may not execute at runtime.
Reachability Verdict
The output classification for a given vulnerability, indicating whether the vulnerable code is reachable, not reachable, or undetermined given the available analysis context. Verdicts are bounded by the scope and assumptions of the analysis.
Dependency Graph Integration
The incorporation of transitive dependency relationships so that reachability can be assessed not just for direct dependencies but also for libraries introduced indirectly through the dependency tree.
Common questions
Answers to the questions practitioners most commonly ask about Reachability Analysis.
Does reachability analysis eliminate false positives from SCA tools entirely?
No. Reachability analysis significantly reduces false positives by filtering out vulnerable code paths that cannot be reached during execution, but it does not eliminate them entirely. Analysis tools may still flag paths that appear reachable in the static call graph but are blocked by runtime conditions, configuration, or data values that cannot be determined without execution context. The reduction in false positives is substantial in most cases, but some degree of over-reporting typically remains.
Does a vulnerability being marked 'unreachable' mean it poses no risk?
Not necessarily. Reachability analysis determines whether a vulnerable function or code path can be invoked based on static or dynamic call graph construction, but it cannot account for all threat scenarios. A dependency marked unreachable today may become reachable after a code change, a configuration update, or the addition of a new feature. Additionally, reachability analysis scopes to the analyzed application and may miss indirect invocation paths, plugin architectures, or runtime reflection patterns that obscure the true call graph.
At what point in the development lifecycle should reachability analysis be applied?
Reachability analysis is most effective when integrated into the CI/CD pipeline so that each build or pull request is evaluated against the current call graph. Applying it only at release time risks accumulating unremediated vulnerabilities. Some teams also run it as part of scheduled dependency audits. Because the call graph changes as code evolves, the analysis should be re-run whenever dependencies or application code are updated, not treated as a one-time assessment.
What inputs does a reachability analysis tool typically require to construct a call graph?
Most tools require access to the application source code or compiled artifacts, the resolved dependency tree including transitive dependencies, and in some cases build configuration or entry point definitions. Static reachability tools analyze the code without execution, while dynamic approaches require a running application and representative workloads or test suites. Tools relying solely on the dependency manifest without code access cannot perform true reachability analysis and instead apply heuristics or ecosystem-level call graph data.
How does reachability analysis handle dynamic language features such as reflection, dynamic dispatch, or runtime code loading?
This is a known limitation for most static reachability tools. Reflection, dynamic class loading, serialization mechanisms, and similar runtime features can create call paths that are invisible to static analysis. Tools may partially handle these cases through heuristics or configurable over-approximation, but coverage is typically incomplete. Teams relying on dynamic language features should supplement static reachability analysis with dynamic analysis techniques or manual review to reduce false negatives in these areas.
How should teams prioritize remediation when reachability analysis produces both reachable and unreachable findings?
Reachable vulnerabilities with high or critical severity scores should generally be prioritized first, as they represent the most direct risk given the analyzed codebase. Unreachable vulnerabilities can typically be deprioritized for immediate patching but should not be ignored entirely. Teams should establish a review cadence for unreachable findings because reachability status can change as the application evolves. Risk tolerance, regulatory requirements, and the confidence level of the reachability tool should all factor into the prioritization policy.
Common misconceptions
A 'not reachable' verdict from reachability analysis means a vulnerability is completely safe to ignore indefinitely.
Reachability is assessed against the codebase and entry points at a specific point in time. Code changes, new entry points, or updated dependencies can alter reachability status. A not-reachable verdict reduces immediate priority but does not eliminate the need for eventual remediation or periodic reassessment.
Reachability analysis can definitively determine whether a vulnerability is exploitable in a production environment.
Reachability analysis operates primarily at the static code level and can confirm whether a vulnerable code path can be invoked. It typically cannot account for runtime conditions such as specific input values, authentication state, environment configuration, or network exposure that are required for actual exploitation.
Reachability analysis eliminates false positives from software composition analysis entirely.
Reachability analysis reduces false positives by filtering out vulnerabilities in code that is not invoked, but the analysis itself can introduce its own false positives through over-approximation of call graphs, and may produce false negatives when dynamic language features, reflection, or runtime code loading are present.
Best practices
Define and maintain a comprehensive, up-to-date set of application entry points before running reachability analysis, as incomplete entry point coverage is a primary source of false negatives.
Treat reachability verdicts as time-sensitive artifacts. Re-run analysis after any significant code change, dependency update, or architectural modification, since reachability status can change as the codebase evolves.
Use reachability results to prioritize remediation effort rather than to permanently close vulnerability findings. Retain not-reachable vulnerabilities in a tracked backlog and apply a defined review cadence.
Understand the specific limitations of the reachability tool in use, particularly its handling of dynamic language features such as reflection, metaprogramming, and runtime class loading, and apply compensating manual review for those categories.
Combine reachability analysis with runtime security controls and monitoring rather than relying on static reachability alone, since static analysis cannot capture all runtime exploitability conditions.
Validate reachability tool accuracy periodically by testing known-reachable paths against tool verdicts, which helps surface systematic false negative behavior before it creates gaps in vulnerability management.