Dependency alerts are now a routine part of software development. A typical JavaScript application may depend on hundreds of packages, many of which bring additional transitive dependencies into the project.
When vulnerabilities are reported, developers are expected to evaluate affected packages, determine their significance, and apply updates without introducing regressions.
The difficulty is that traditional dependency alerts generally identify vulnerable package versions without establishing whether the application actually calls the affected code.
On October 28, 2026, GitHub introduced reachability analysis for Dependabot alerts in public preview. The feature adds a new dimension to vulnerability prioritization by examining whether an application’s code can reach a known vulnerable function.
For development and security teams dealing with large dependency trees, this information could make vulnerability triage more focused. But reachability should not be confused with proof of exploitability.
The Limitations of Traditional Dependency Alerts
Consider an application that includes a library containing a vulnerable function. A dependency scanner detects that the installed package version is affected and creates an alert.
At that point, several questions remain unanswered. Does the application import the vulnerable functionality? Is it reachable from production code? Does an attacker control the input required to trigger the flaw?
Two applications using the same vulnerable package may have very different exposure levels. One might execute the affected function during every request, while another might never invoke it.
Severity ratings and vulnerability advisories remain important, but they cannot fully describe how a particular application uses a dependency.
How Reachability Analysis Works
GitHub’s new feature combines Dependabot advisory information with static code analysis.
For supported advisories, GitHub maintains curated information identifying the vulnerable functions within affected packages. CodeQL then constructs a call graph covering the application’s code and its dependencies.
The analysis searches for paths that connect application code to those vulnerable functions.
When a path is found, the corresponding Dependabot alert can display evidence explaining how the vulnerable code is reached.
This goes beyond simply knowing that a package exists in package-lock.json, pnpm-lock.yaml, or yarn.lock.
Four Possible Reachability Results
GitHub provides four verdicts for analyzed alerts.
- Reachable: At least one call path was found between application code and the vulnerable function.
- Potentially reachable: The analysis cannot rule out a call to the vulnerable function. These alerts should receive attention comparable to reachable findings.
- Unreachable: The analysis completed without finding a call path. The alert may receive a lower priority, but should not be automatically dismissed.
- Reachability unavailable: The analysis could not produce a result, perhaps because the repository is unsupported or the scan failed.
These verdicts supplement existing security information. They do not close alerts, change advisory severity, or establish whether an attacker can successfully exploit a vulnerability.
An Example from a JavaScript Application
Imagine an application that includes a hypothetical dependency named example-parser. A security advisory identifies one of its parsing functions as vulnerable when processing specially crafted input.
Application code might call the library through a helper module:
import { parseDocument } from "example-parser";
export function processUpload(content) {
return parseDocument(content);
}If parseDocument() were identified as vulnerable, reachability analysis could potentially identify the call path from processUpload() to the affected function.
This example is illustrative. The package name and vulnerability are hypothetical, not a real security advisory.
Even with a reachable result, further investigation would be required to establish whether users can supply the relevant input and whether the application’s execution environment satisfies the conditions described in the advisory.
Enabling Reachability Analysis
During the public preview, reachability analysis is available for GitHub Enterprise Cloud repositories, including organizations using Enterprise Cloud with data residency.
The current implementation supports JavaScript and TypeScript projects using npm, Yarn, or pnpm lockfiles.
Dependabot alerts must already be enabled. Administrators can activate reachability analysis through repository security settings or organizational security configurations.
GitHub runs the analysis through managed GitHub Actions infrastructure. Repository maintainers do not need to install a local scanner or maintain a separate analysis workflow.
The feature is free during the preview and does not consume billed GitHub Actions minutes. GitHub states that a separate Code Security license is not required.
Understanding the Operational Limitations
The new analysis is not yet available for every programming language or package ecosystem. PHP Composer dependencies, for example, are outside the current JavaScript and TypeScript scope.
Repositories using self-hosted runners are not supported by the analysis during the preview, which relies on GitHub-hosted infrastructure.
Large monorepos and projects with complicated dependency layouts may encounter limitations, including scans that exceed the current three-hour execution limit.
Results are also not instantaneous. After the initial scan, GitHub refreshes reachability information approximately every 24 hours while open alerts remain. Pushing new code does not immediately trigger a new assessment.
This delay matters when developers change a dependency call path and expect the alert’s verdict to reflect the modification.
Reachability Is Not Exploitability
One of the most important distinctions is between a function being reachable and a vulnerability being exploitable.
A vulnerable function may be called only with trusted constants, sanitized values, or under conditions inaccessible to an attacker.
Conversely, static analysis can miss dynamically constructed calls or fail to resolve complex execution paths.
An unreachable verdict should therefore never become an automatic justification for permanently ignoring a security update.
Teams should combine reachability with advisory severity, exploit prediction scores, production exposure, available patches, and knowledge of how the application actually operates.
What This Changes for Security Teams
For teams with hundreds of open alerts, the main benefit is better prioritization. Instead of treating every affected package as equally urgent, they gain evidence about how their application interacts with vulnerable code.
That evidence can also improve communication between security specialists and developers. A finding accompanied by a concrete call path is easier to investigate than a generic alert containing only a package name and version range.
Reachability results are available through the Dependabot alerts REST API, allowing organizations to incorporate them into existing vulnerability-management dashboards and reporting systems.
Conclusion
GitHub’s reachability analysis introduces a useful improvement to dependency security by connecting vulnerability information with actual application code.
Its current scope is limited, and the feature remains in public preview. Nevertheless, the underlying approach addresses a practical problem: dependency vulnerability management needs context, not just longer lists of alerts.
For eligible teams, reachability analysis offers another signal for deciding which problems to investigate first, while preserving the need for careful technical judgment.
