9 min read - Dependabot Reachability: Prioritize Fixes Without Closing Alerts

GitHub announced reachability analysis for Dependabot alerts in public preview on 28 October 2026. For supported JavaScript and TypeScript repositories, the service looks for call paths from application code to functions identified as vulnerable. A security team can now see more than package presence and severity when deciding which update to take first.

The new signal solves a queue-ordering problem. It does not decide whether a system is safe, whether an attacker can exploit a path, or whether an alert may be closed.

For a small security team, the practical task is to add reachability to the remediation policy without creating a new excuse to postpone dependency work.

Read the verdict as evidence, not a disposition

GitHub's 28 October announcement describes a managed analysis that combines curated vulnerable-function data with a CodeQL call graph. It assigns one of four verdicts to each eligible open alert.

GitHub's reachability documentation says the feature neither closes nor dismisses alerts. It also says an unreachable verdict is not proof that a dependency is safe. Code changes, an updated advisory or a later scan can change the result.

A reachable path is not proof of exploitability either. The path shows that application code can arrive at the affected function. Authentication, input control, runtime configuration and compensating controls still determine whether an attacker can use that path.

Combine four questions in the queue

Severity alone makes a poor work plan. Reachability improves local context, but a remediation decision still needs four separate questions.

1. Is exploitation confirmed or becoming more likely? Check vendor advisories, trusted threat intelligence, known-exploitation records and EPSS. FIRST defines EPSS as a daily estimate of the probability that exploitation activity will be observed in the next 30 days. FIRST also warns that EPSS is not a complete risk score and does not know your environment.
2. Can application code reach the vulnerable function? Use the verdict and call path as evidence. Potentially reachable means uncertainty remains; unavailable means the tool supplied no answer.
3. Can an attacker satisfy the conditions? Check the exposed entry point, required privileges, input path, runtime flags and any isolation that affects the actual deployment.
4. What happens if exploitation succeeds? Add the affected service, data, business process, recovery effort and current production status.

These questions prevent two common errors. A critical package with no relevant path can consume an emergency slot while a reachable, lower-severity flaw on an exposed service waits. The reverse is also possible: an unreachable verdict can obscure high consequence, weakly understood code when the scan is stale or incomplete.

NIST's Secure Software Development Framework (SP 800-218, version 1.1) recommends integrating vulnerability response into the software development life cycle, reducing the impact of unaddressed flaws and addressing root causes. The framework is broad and product-neutral. It does not endorse GitHub's implementation or replace a team's own risk decision.

Put policy around the change in priority

A queue needs explicit transitions. Without them, a new label either sits unused on a dashboard or turns into an undocumented closure rule.

The table is a starting policy, not a universal service-level commitment. Each team should set time bands from its own release capacity, system criticality and incident experience. A promise to fix every reachable alert immediately will not hold up against a busy product backlog, and neither will a policy with no owner or review date.

Record the reason whenever reachability changes the order. The minimum useful note is short: verdict, scan time, affected deployment, exploit evidence, consequence, chosen owner and next review. That note lets a reviewer understand why an alert moved without reconstructing an old dashboard.

Our guide to production dependency upgrade gates explains how to separate a dependency update from the proof needed to release it. The same principle applies here: reachability can increase urgency, but tests and rollout evidence still decide whether the fix is ready.

Do not automate closure from a point-in-time result

GitHub says scans run every 24 hours while eligible open alerts exist. A code push does not trigger a new scan, and the public preview does not support an on-demand run. There can therefore be a period when the displayed verdict describes yesterday's code rather than the commit under review.

That timing rules out a simple “unreachable equals dismiss” automation. It also affects release gates. Suppose a pull request introduces a new call to an already vulnerable dependency. The existing alert may keep its unreachable verdict until a later scan analyses code that includes the change. A workflow that reads the label alone would approve with stale evidence.

Use automation for collection and routing instead:

• copy the verdict, scan time and alert link into the work item;
• raise reachable and potentially reachable results in the queue;
• flag unavailable or old results for manual review;
• preserve the original alert until the dependency is updated or a documented risk decision uses wider evidence.

If an agent consumes the Dependabot REST API, give it the same boundary. It may prepare the queue and assemble evidence. It should not silently dismiss alerts or change accepted-risk records. Our guide to findings and verified patches sets out the evidence gap between finding a flaw and accepting a patch.

Pilot the operating process

Reachability analysis is off by default. During the preview, GitHub lists support for GitHub Enterprise Cloud repositories using JavaScript or TypeScript with an npm, Yarn or pnpm lockfile. The analysis uses GitHub-hosted runners; self-hosted runners are not supported. GitHub says the preview is free, needs no GitHub Advanced Security licence and does not consume billed Actions minutes. It also warns that some monorepos and repositories with manifests in several directories may not be supported during the preview, and that analyses running longer than three hours may return “Reachability unavailable”.

Start with a representative set of repositories rather than an organisation-wide closure policy. Include an ordinary service, a repository with several manifests and one with a meaningful alert backlog. Before enabling the feature, capture the current queue, the time spent on triage and the reasons alerts remain open.

During the pilot, review several reachable, potentially reachable, unreachable and unavailable results. Trace the sample paths against the deployed application. GitHub shows up to five sample paths and says they are not exhaustive, so absence from the display is not proof that no other path exists.

Measure decisions, not label counts:

• Did the new evidence move genuinely urgent work earlier?
• How often did a reviewer disagree with the proposed order, and why?
• Did monorepos, generated code or multiple manifests produce unavailable or uncertain results?
• How long did verdicts lag behind dependency or application changes?
• Did the team still update lower-priority packages through normal maintenance?

At the end, keep the feature if it reduces time spent reconstructing call paths and improves the order of fixes. Adjust the policy if reviewers repeatedly need context the verdict cannot supply. Stop short of enforcement if scan coverage does not match the repositories where the largest consequences sit.

Keep a decision record that can age

A prioritization result goes stale as code, advisories and deployments change. Store enough context to revisit it: repository and commit, alert and advisory, reachability verdict, scan time, deployed version, EPSS or confirmed-exploitation evidence, consequence, owner and review date. When the dependency, code path, advisory or deployment changes, reassess the record.

In a small team, limited remediation capacity makes ordering necessary, but it also makes forgotten low-priority work more likely. Keep a maintenance lane for unreachable alerts and report age as well as severity. A queue that only watches new reachable alerts will build an old dependency base behind it.

Use the call path to decide where to look first. Combine it with attacker activity and business consequence, and keep the evidence behind each decision.

Explore Exceev's cybersecurity and engineering services if your team needs to define a vulnerability queue, test a dependency-update process or connect findings to release evidence.

Sources and limitations

We opened and reviewed every source below on 29 October 2026 and checked them again on 4 November 2026.

• GitHub's release announcement is the primary source for the public-preview date, supported plans and ecosystems, managed CodeQL analysis, verdicts, current cost statement and initial rollout path.
• GitHub's reachability documentation defines the verdict limits, scan timing, sample-path limit, runner restriction and warning against dismissal based only on reachability.
• FIRST's EPSS guidance independently defines what EPSS estimates and why it is not a complete environment-specific risk score.
• NIST's Secure Software Development Framework supplies independent, product-neutral guidance for integrating vulnerability response into software development.

We did not enable the preview, inspect GitHub's curated vulnerable-function data or test CodeQL's results on a production repository. Availability, pricing, coverage and scan behaviour may change during the preview. The queue policy, pilot design and decision record are Exceev's analysis, not GitHub, FIRST or NIST requirements. This article is technical guidance, not a guarantee that a verdict establishes safety, exploitability or compliance.