What Is Reachability Analysis in AppSec? How to Identify Reachable Vulnerabilities

What Is Reachability Analysis in AppSec? How to Identify Reachable Vulnerabilities

A vulnerability scanner finds a critical issue in one of your application's dependencies.

The severity score is high. The package exists in your environment. The finding lands in the AppSec backlog.

But there is another question worth answering before treating that finding like every other critical vulnerability:

Can your application actually reach the vulnerable code?

That is the problem vulnerability reachability analysis is designed to help answer.

Instead of looking only at whether vulnerable software is present, reachability analysis adds application-specific context. It examines how your code interacts with its dependencies and whether an execution path can lead to the vulnerable function, method, or code element associated with a finding.

For AppSec teams dealing with large volumes of scanner output, that distinction can make vulnerability investigation significantly more useful.

What Is Vulnerability Reachability Analysis?

Vulnerability reachability analysis is the process of determining whether application code can reach or invoke the specific vulnerable code associated with a security finding.

This is especially useful in Software Composition Analysis (SCA).

An SCA tool might identify that your application includes a dependency with a known CVE. However, a package can contain hundreds or thousands of functions. Your application may use the package without ever invoking the particular function where the vulnerability exists.

Reachability analysis examines that relationship.

Rather than stopping at:

"Is the vulnerable package installed?"

it asks:

"Is there a valid path from the application to the vulnerable code?"

OWASP's DevSecOps guidance describes reachability analysis as identifying vulnerable functions and using the application's call graph to determine whether execution can reach them. Snyk similarly describes reachability as identifying whether an application calls code elements associated with a vulnerability.

That makes reachability an application-context signal rather than simply another vulnerability severity score.

Why Vulnerability Severity Alone Does Not Tell You What Is Reachable

Severity is useful, but it answers a different question.

A CVSS score describes characteristics of a vulnerability and its potential severity under defined conditions. It does not automatically tell you how your particular application uses the affected code.

Imagine two applications using the same vulnerable dependency.

Application A imports the package but never calls the vulnerable function.

Application B calls that vulnerable function from a code path triggered by an API request.

The underlying CVE may be identical.

The application context is not.

Traditional dependency scanning is good at discovering that vulnerable software is present. Reachability analysis adds another layer by examining whether the vulnerable portion of that software participates in an application execution path.

This is why two identical dependency findings can deserve very different investigation paths.

How Does Reachability Analysis Work?

Implementation varies between security platforms, languages, and analysis techniques, but the basic workflow generally looks like this.

1. Identify the vulnerable code

The process begins with a security finding.

For an open-source dependency, that might mean identifying the package and version associated with a CVE and then determining which function, method, class, or code element contains the vulnerable behavior.

... (163 more lines after line 60)

Knowing only that a package is affected is not enough for function-level reachability. The analysis needs to know what vulnerable code it is attempting to reach.

2. Map application and dependency relationships

The system then analyzes the application structure.

That can include application code, imported packages, transitive dependencies, function calls, modules, services, and application entry points.

Static program analysis can be used to construct a call graph representing potential paths between functions.

For example:

API handler → application service → dependency method → vulnerable function

The deeper the dependency tree, the more valuable this mapping becomes. A vulnerable component may exist several levels below the dependency your developers intentionally installed.

3. Trace possible call paths

Reachability analysis then asks whether a path connects application execution to the vulnerable code.

If a valid call path exists, the vulnerability may be classified as reachable.

If analysis can determine that the vulnerable function cannot be called through the application's known execution paths, it may be classified as unreachable.

Some systems may also return an unknown or uncertain result when the analysis cannot confidently determine reachability.

That distinction matters. Dynamic language behavior, reflection, dependency injection, runtime configuration, native code, framework behavior, and other factors can make some call paths difficult to resolve through static analysis alone.

4. Classify the finding

The result adds context to the original vulnerability.

Instead of seeing only:

Critical — vulnerable dependency detected

the AppSec engineer may now have something closer to:

Critical — vulnerable function reachable from application code

or:

Critical — vulnerable dependency present, but no path to the vulnerable function identified

The severity did not change.

The team's understanding of the finding did.

5. Add additional security context

Reachability should not be the end of the investigation.

Once vulnerable code is known to be reachable, AppSec still needs to understand conditions such as:

whether attacker-controlled input can reach the vulnerable path

whether authentication or authorization protects the path

whether specific runtime configuration is required

whether compensating controls exist

whether the vulnerable functionality is exposed in production

what impact successful exploitation could have

That is where reachability starts to connect with broader exploitability analysis and vulnerability triage.

Reachability vs. Exploitability

These concepts are related, but they should not be treated as synonyms.

Reachability asks whether execution can reach vulnerable code.

Exploitability asks whether an attacker can successfully abuse the vulnerability under the application's actual conditions.

... (showing lines from 61, 60 lines before not shown)

... (103 more lines after line 120)

A function can be reachable without necessarily being exploitable.

For example, the vulnerable function could require trusted input, sit behind an authentication boundary, depend on a disabled configuration, or be protected by another security control.

Current industry guidance explicitly cautions against using reachability as a complete exploitability verdict. Reachability establishes important execution context, but additional evidence is needed to determine whether an attacker can turn that path into meaningful impact.

So the useful mental model is:

Reachable does not automatically mean exploitable.

But a confirmed reachable path often gives the security team a much better place to begin deeper investigation.

A Simple Reachability Analysis Example

Suppose your application depends on a document-processing library.

A new CVE is published affecting a specific parsing method within that library.

Your SCA scanner identifies the vulnerable package in 20 repositories.

Without additional context, all 20 repositories may appear to contain the same vulnerability.

Reachability analysis changes the picture.

In 15 repositories, the library is present because another dependency requires it, but the vulnerable parser is never called.

In four repositories, the library is used, but only unrelated functions appear in application call paths.

In one internet-facing service, an upload endpoint eventually calls the vulnerable parsing function.

Those 20 findings now represent very different application contexts.

That does not automatically prove the final repository is exploitable. You still need to understand input control, runtime conditions, existing mitigations, and other factors.

But reachability has narrowed the investigation from:

"Twenty applications contain this vulnerable package."

to:

"One application has a known execution path to the vulnerable code."

That is a much more actionable starting point.

How Reachability Helps AppSec Teams

The biggest benefit of reachability analysis is not that it makes vulnerabilities disappear.

It gives security engineers better information about where to spend investigation time.

It adds application context to dependency findings

Package presence alone tells you what software exists. Reachability helps tell you how that software participates in the application.

It helps distinguish findings that deserve deeper investigation

When hundreds of findings share similar severity scores, reachability creates another useful dimension for deciding where additional security analysis is warranted.

It can reduce unnecessary developer work

Developers are more likely to trust security findings when AppSec can explain why vulnerable code is relevant to their application rather than simply forwarding raw scanner output.

It improves incident response to newly disclosed vulnerabilities

When a significant dependency vulnerability is disclosed, teams often need to determine exposure across many repositories quickly. Knowing where the vulnerable function is actually reachable can help focus that investigation.

This is why reachability has become an increasingly important part of risk-based vulnerability prioritization rather than a replacement for vulnerability scanning itself.

What Reachability Analysis Cannot Tell You

Reachability is powerful precisely because it answers a specific question. It should not be expected to answer every security question.

Reachability alone does not necessarily tell you:

... (showing lines from 121, 120 lines before not shown)

... (43 more lines after line 180)

whether an attacker controls the required input

whether the application is externally exposed

whether runtime controls prevent exploitation

whether a particular configuration activates the vulnerable behavior

what business impact exploitation would create

whether the vulnerability should automatically become the team's highest remediation priority

Analysis quality can also depend on the programming language, framework, code visibility, and the techniques being used. Some execution paths are straightforward to model statically. Others depend heavily on runtime behavior.

The strongest AppSec decisions therefore combine reachability with additional signals such as exploitability, exposure, business criticality, configuration, threat intelligence, environmental context, and organizational policy.

Where Does Reachability Fit Into Vulnerability Triage?

Reachability is best viewed as one input into vulnerability triage, not the entire triage process.

A broader triage workflow may include validating the finding, removing duplicates, checking reachability, evaluating exploitability and exposure, identifying application ownership, understanding business impact, and then determining remediation priority.

If you want the complete workflow, see What Is Vulnerability Triage? A Practical AppSec Workflow.

Keeping those concepts separate is important: reachability answers whether vulnerable code participates in an application path; triage determines what the security team ultimately does with the finding.

Turning Reachability Context Into Remediation

Reachability becomes most valuable when the result can move directly into the rest of the security workflow.

Knowing that a vulnerability is reachable is useful. Knowing it is reachable, understanding the surrounding application context, validating its significance, assigning the right owner, and getting a fix in front of the developer is much more valuable.

That is the workflow Amplify is building around. Amplify Console connects security findings with contextual triage, reachability analysis, and remediation workflows. Amplify's reachability analysis maps code paths to production so teams can understand which findings deserve investigation before spending manual triage time, then connects that result directly into triage and automated fix workflows rather than leaving it inside another disconnected dashboard.

For AppSec teams, that is the larger goal. Not simply identifying more vulnerabilities, but turning the findings you already have into security work that can actually move forward.

Frequently Asked Questions

What is vulnerability reachability? Vulnerability reachability describes whether an application's execution paths can reach the specific vulnerable code associated with a security finding. A dependency can contain a known vulnerability without the application necessarily invoking the vulnerable function.

Is reachability the same as exploitability? No. Reachability determines whether vulnerable code can be reached through an application path. Exploitability considers whether an attacker can actually abuse that vulnerability given inputs, configuration, exposure, security controls, and other runtime conditions.

Can a critical vulnerability be unreachable? Yes. A dependency can contain a critical vulnerability even when the application does not use the vulnerable portion of the component. The severity of the underlying CVE and its reachability within a specific application describe different things.

Does a reachable vulnerability always need to be fixed immediately? Not necessarily. Reachability is an important prioritization signal, but AppSec teams should also evaluate exploitability, exposure, business criticality, available mitigations, threat activity, and organizational policy before determining remediation priority.

How does reachability analysis reduce security noise? Reachability analysis provides application-specific context to security findings. Instead of treating every vulnerable dependency as equally relevant, teams can identify which findings have known paths to vulnerable code and focus deeper investigation accordingly.

Move Beyond Raw Scanner Severity

See how Amplify combines application context, reachability analysis, contextual triage, and remediation workflows to help security teams turn findings into action.

Book a demo with Amplify