Too many Dependabot alerts? Follow the path to the vulnerable function
The same package name in two security alerts does not necessarily imply the same repair priority. One service may call the vulnerable function while handling a request; another may install the package without using that function. GitHub's October 28, 2026 public preview of Dependabot reachability analysis brings that distinction into the alert workflow.
From installed packages to call paths
Dependabot identifies vulnerable dependency versions. The new analysis looks for a path from repository code to the affected function. A GitHub-managed Actions workflow uses CodeQL to build a call graph across the repository and its dependencies, then checks curated advisory data identifying vulnerable functions.
The illustration below uses invented code. An order API reaches package.parseUnsafe through a helper, while another entry point only calls package.formatLabel. That second route does not reach the target in this example graph. This is not a real package vulnerability or a reproduction of GitHub's analyzer. It shows why an installed package alone is an incomplete description of exposure.
Four verdicts, four different meanings
Reachable means at least one call path was found. It does not establish that an attacker can exploit the issue. Whether external input can reach that path and whether it runs in production still matter. An alert can show up to five sample paths; these are examples rather than a complete inventory.
Potentially reachable means analysis could not rule out a call and should be prioritized alongside Reachable. Unreachable means analysis completed without finding a path. Reachability unavailable means it could not provide a verdict at all. Treating the last two as the same reassuring signal loses important information. None of these verdicts automatically closes or dismisses an alert.
A code change does not immediately change the verdict
Timing is easy to miss. Enabling the feature starts an initial scan; further scans run every 24 hours while open Dependabot alerts remain. A push does not trigger an immediate scan, and the public preview does not offer on-demand scanning.
For example, removing the vulnerable call from an order handler today may leave yesterday's Reachable verdict visible until the next scan completes. Adding a call can likewise leave an older Unreachable label temporarily visible. The second illustration is actual Python traversal output for the invented graph. For a real fix, connect the completed scan's timing with the code it assessed before interpreting the label.
Where you can start
The preview is available on GitHub Enterprise Cloud, including data residency. It supports JavaScript and TypeScript repositories with an npm, Yarn, or pnpm lockfile and enabled Dependabot alerts. It does not require a GitHub Code Security license. Preview scans are free and do not consume billed Actions minutes; self-hosted runners are unsupported.
It is off by default. Enable it under repository Settings > Advanced Security, or through a custom organization or enterprise security configuration. Large monorepos can encounter the three-hour scan limit or resource limits, leaving unavailable results. Severity, EPSS and production exposure still complete the picture. The useful change is stronger evidence for deciding which open alert deserves attention first.