GitHub has started a public preview of reachability analysis for Dependabot alerts. The feature was announced on October 28, 2026, and it works for JavaScript and TypeScript projects that use npm, Yarn or pnpm.
The idea is simple. Having a risky package installed does not mean your application ever runs the risky function inside it. The new check answers that question and tags every open alert with a verdict, so teams know where to begin.
What Reachability Analysis Does
For each Dependabot alert, GitHub now looks for a path from your own code to the specific function that contains the vulnerability. The evidence is shown on the alert page, next to the details you already know.
GitHub is clear that this is one signal among several. It suggests using it together with severity, the EPSS score, production context and your own knowledge of the application.
How the Analysis Works
The analysis runs inside a managed GitHub Actions workflow that GitHub operates, so there is nothing to install or maintain in your repository. For every advisory, GitHub uses curated data that names the vulnerable functions of the affected package.
CodeQL maps which function calls which, across your repository and the packages it uses. It then looks in that map for a route that ends at each vulnerable function.
Every open alert gets one of four verdicts:
- Reachable: at least one call path leads from your code to the vulnerable function.
- Potentially reachable: the analysis could not decide, and GitHub advises treating the alert as reachable.
- Unreachable: the analysis finished and found no path, so the alert is a lower priority.
- Reachability unavailable: the alert could not be analyzed, so triage it as usual.
A verdict never closes or dismisses an alert on its own. The repository and organization alert pages let you filter and order alerts by verdict. The Dependabot alerts REST API exposes the same data to your own tools.
Availability and Limits During the Preview
The preview costs nothing. No Advanced Security license is required, and the Actions minutes consumed by the scans are not charged.
It is limited in several ways:
- It is available on GitHub Enterprise Cloud, including the data residency option.
- Only JavaScript and TypeScript are supported, and the repository needs an npm, Yarn or pnpm lockfile.
- The analysis runs on GitHub-hosted runners only. Self-hosted runners are not supported yet.
- Some monorepos, and repositories with manifest files in several directories, may not be supported.
- If a run takes longer than three hours, some alerts may show "Reachability unavailable".
All GitHub-reviewed JavaScript advisories in the GitHub Advisory Database that trigger Dependabot alerts are covered.
What It Means for Developers
Many teams have a long list of open dependency alerts, and most of them sit untouched because nobody knows where to start. A verdict gives a quick first filter. Reachable alerts can go to the top of the sprint, while unreachable ones can wait for the next routine update.
Be careful with the "unreachable" label. It describes what a static call graph could find, and it can miss code that loads modules dynamically. Keep fixing critical issues that are exposed to the internet, even if the verdict looks calm.
Teams that build internal dashboards or AI agents for security triage can also use the REST API. They can sort alerts by verdict and feed only the reachable ones into their own workflow.
How to Get Started
Reachability analysis is off by default. To turn it on for many repositories together, define a security configuration at the enterprise or organization level. For a single repository, open Settings, then Advanced Security, and look in the Dependabot section.
Dependabot alerts must already be turned on, or no verdicts will appear. The first scan begins right away, and its duration ranges from minutes to hours depending on the project. Later scans repeat daily while the repository has open alerts, so verdicts follow changes in your code and in the advisories.
Conclusion
Reachability analysis will not remove the need to patch dependencies, but it helps teams spend their time on the alerts that matter most. If you use Enterprise Cloud with a JavaScript or TypeScript codebase, it is worth switching on during the free preview and comparing the verdicts with your current triage habits.
Sources
See my articles more often when you search Google.
