Dependabot Reachability Analysis: Preview Limits and Verdicts

GitHub introduced a public preview of reachability analysis for Dependabot alerts on October 28, 2026. For eligible JavaScript and TypeScript repositories, CodeQL builds a call graph and looks for paths from application code to vulnerable dependency functions. The result adds prioritization evidence; it does not dismiss or repair an alert.

Four verdicts describe different levels of evidence

“Reachable” means at least one call path was found. “Potentially reachable” means the analysis could not decide and GitHub says to treat it as reachable. “Unreachable” means the completed analysis found no path. “Reachability unavailable” means the alert could not be analyzed and should follow normal triage.

A missing static call path is not proof that exploitation is impossible. Reflection, dynamic loading, configuration, generated code and runtime data may escape a call graph. Teams should combine the verdict with severity, EPSS, deployment context and knowledge of the application.

The preview has a narrow eligibility envelope

The preview supports JavaScript and TypeScript repositories with npm, Yarn or pnpm lockfiles on GitHub Enterprise Cloud, including data residency. It runs on GitHub-hosted runners; self-hosted runners are not supported. Some monorepos and repositories with manifests in several directories may not be supported.

Analysis that exceeds three hours may return unavailable results. Coverage depends on curated vulnerable-function data for GitHub-reviewed JavaScript advisories. These limits should be documented before comparing alert counts across repositories.

The managed workflow is free during preview but off by default

GitHub says the analysis is free during the preview, does not consume billed Actions minutes and does not require Advanced Security. Dependabot alerts must be enabled, and administrators turn reachability on through a custom security configuration or repository setting.

The first scan may take minutes or hours and reruns daily while open alerts exist. Organizations should monitor scan status and avoid treating a stale or unavailable verdict as current evidence after code or dependency changes.

Prioritization must not become silent acceptance

Verdicts never close or dismiss an alert. An unreachable result may justify lower priority, but teams should still update within a risk-based service level, especially when exposure can change through a future code path. Reachable findings need patch testing rather than an automatic assumption that the suggested upgrade is harmless.

For Canadian organizations operating regulated services, retain the advisory, verdict, application context and decision owner. Reachability can focus scarce review time, but accountability remains with the team that accepts or remediates the risk.

Sources and editorial method

We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.

GitHub: Prioritize Dependabot alerts with reachability analysis ↗ — Official October 28 preview announcement; verdicts, implementation, eligibility and cost.