Skip to main content

Prioritize Dependabot alerts with reachability analysis

By Steven Van ·

Free in public preview for GitHub Enterprise Cloud, it labels JavaScript and TypeScript alerts as reachable, potentially reachable or unreachable.

Dependabot alerts on GitHub can now carry a reachability verdict. Reachability analysis is in public preview for JavaScript and TypeScript. It checks whether a repository's code can call the vulnerable function in a dependency, and shows the evidence on each alert.

How it works

Dependabot runs the analysis in a managed GitHub Actions workflow, so nothing needs to be installed or maintained. For each advisory, curated data identifies the vulnerable functions in the affected package. CodeQL builds a call graph across the repository and its dependencies, then searches it for a path from the code to those functions.

For reachable alerts, call-path evidence shows how the code leads to the vulnerable function. An alert can show up to five sample paths, which are not an exhaustive list.

The four verdicts

  • Reachable: at least one call path from the repository's code to a vulnerable function. Prioritize remediation and review the evidence.
  • Potentially reachable: the analysis could not rule out a call. In repositories with multiple manifests, calls found only outside a manifest's directory count here. Treat these as reachable.
  • Unreachable: the analysis completed and found no call path. These alerts are lower priority, but should not be dismissed or closed solely because of this verdict.
  • Reachability unavailable: no verdict could be given, for example because of an unsupported ecosystem or a failed or timed-out scan. Triage as usual.

Verdicts never close or dismiss an alert. GitHub says to use them alongside severity, EPSS score, dependency scope and relationship, and knowledge of the application. A reachable function is not necessarily exploitable, and an unreachable verdict does not guarantee a dependency is safe.

Where verdicts appear

Verdicts show on the existing Dependabot alerts pages. Alerts can be filtered and sorted by verdict on the repository and organization pages. The Dependabot alerts REST API exposes verdicts through the repository, organization and enterprise endpoints.

Availability and requirements

  • Plans: GitHub Enterprise Cloud, including data residency, for public, private and internal repositories.
  • Cost: free during the preview. No GitHub Code Security license is needed, and scans do not use billed Actions minutes.
  • Languages: JavaScript with npm, pnpm or Yarn, and TypeScript. A lock file such as package-lock.json, pnpm-lock.yaml or yarn.lock is required.
  • Setup: Dependabot alerts must be enabled. Scans run on GitHub-hosted runners, and self-hosted runners are not supported.

When results update

Enabling the feature starts an initial scan of open alerts. After that, a scan covering all open alerts runs every 24 hours while the repository has any. Pushing code does not trigger a scan, and on-demand or scheduled scans are not available in the preview. Scans have a three-hour limit, so large repositories and monorepos may end up with no result.

GitHub
GitHub
Where the world builds software — Git hosting, pull requests, issues, Actions CI/CD, and Copilot, free for public and private repos.
View GitHub →
Sources

Original source

Read Prioritize Dependabot alerts with reachability analysis on Creators Toolbox