Dependabot reachability preview: keep a triage record

GitHub's Dependabot reachability analysis entered public preview on 28 October 2026. Use it to prioritize open vulnerability alerts, while keeping the evidence, scan freshness and human decision separate. A reachable call path is not proof of exploitability, and an unreachable verdict is not permission to dismiss an alert. A useful pilot improves the triage record before it changes remediation policy. ^[1][2][6]

What changed in the October announcement?#

GitHub added call-path analysis to Dependabot alerts for supported JavaScript and TypeScript repositories. The announcement describes a managed analysis workflow that uses CodeQL and curated information about affected functions. Its output supplements the vulnerability alert with evidence about whether application code can reach the affected function. This is a dated analysis of that announcement, checked against documentation on 31 October 2026. ^[1]

At this observation date, the feature is a public preview for GitHub Enterprise Cloud, including data-residency enterprises, with supported lockfiles and GitHub-hosted analysis. GitHub says the preview does not require a GitHub Code Security license or consume billed Actions minutes. Check the documented requirements against the repository being considered; do not assume every repository with Dependabot alerts qualifies. ^[1][2]

Those boundaries matter when someone asks whether to enable it across an organization. An absent verdict may indicate lack of analysis, not a clean dependency. Inspect verdict coverage in eligible repositories before changing the work queue. The team needs a place to record the call-path evidence before using it to change priority.

The existing package firewall pilot covers a different control point: dependency installation policy. Reachability instead informs review of existing alerts. Keeping these controls separate prevents an installation decision, a code-analysis result and a remediation decision from becoming an ambiguous “dependency security passed” status.

Which decisions belong to each verdict?#

Use the verdict to choose the next investigation, rather than map it directly to an alert state. The documented categories are reachable, potentially reachable, unreachable and reachability unavailable. GitHub directs users to treat potentially reachable alerts alongside reachable ones and use ordinary triage when analysis is unavailable. Unreachable evidence supports lower priority, rather than automatic closure. ^[1][2]

A reachable path identifies a code location and a dependency route worth examining. It does not answer whether attacker-controlled input reaches that path under relevant conditions. Likewise, an unreachable result describes what the analysis found, rather than proving every possible runtime path safe. GitHub's alert-review documentation explicitly separates a call path from proof of exploitation. ^[6]

The response column is our proposed operating policy, not a GitHub requirement. Severity, package scope, exposure and existing incident commitments still influence priority. A vulnerable component reachable only in an internal development task may demand a different response from the same component on a public request path. The verdict supplies a question to investigate, not the whole risk decision.

Preserve the underlying alert identity. Dependabot alerts identify vulnerable dependencies and their affected files and available fixes. Reachability supplements that workflow; it should not become a second, disconnected issue inventory whose records lose the relationship to the package that needs remediation. ^[5]

The worked case: review a checkout API without closing alerts#

Scenario: a fictional team pilots reachability on its JavaScript checkout API. It has open dependency alerts, a committed supported lockfile, and an assigned security owner. The team wants evidence that helps choose review order. It has not agreed to weaken its remediation commitments. The records below are illustrative, contain no real advisory identifiers and report no customer or tenant test results.

The first record concerns a parser dependency on the public import path. Analysis identifies a call path from application code to an affected function. The reviewer preserves the relevant code location and checks whether untrusted documents can reach it. The record's action is to assess and remediate the exposure, with the existing alert left open until the team's normal fix verification is complete.

The second record has a potentially reachable verdict for a shared utility. The team cannot resolve the path confidently from the available evidence. It assigns an engineer to inspect usage and keeps the item in active review. This prevents an uncertainty classification from being translated into a reassuring absence of proof. It also makes the unanswered question visible to the person planning the fix.

The third record is unreachable in the latest completed scan. Its dependency remains present. The reviewer proposes a bounded deferral because the package is outside the currently exposed path and an upgrade needs coordination. The decision record names the owner, rationale and condition that ends the deferral. The alert stays open. This is a proposed team policy, not an assertion that the preview automatically creates that workflow.

The final record is unavailable. It receives the same ordinary vulnerability triage it would have received before the pilot. That is a critical control case: a team should be able to describe useful work when the new analysis contributes nothing. If enabling the preview makes unsupported or failed cases disappear from the work queue, the integration has reduced visibility.

How should the triage record be structured?#

Structure it so another reviewer can distinguish source evidence from a team's judgment. The following JSON is an illustrative internal record, not a Dependabot REST response schema. It deliberately avoids depending on undocumented field names or an inferred API representation. Use your established issue or vulnerability system to store an equivalent record.

{
  "example": "fictional checkout dependency review",
  "alert_reference": "internal-example-parser-alert",
  "repository": "checkout-api",
  "manifest": "package-lock.json",
  "observed_verdict": "unreachable",
  "evidence_context": "latest completed scan reviewed by owner",
  "code_changed_since_review": true,
  "decision": "hold prior deferral for re-review",
  "decision_owner": "application-security-owner",
  "closure_authorized": false,
  "next_check": "review completed analysis and changed call path"
}

The important field is the separation between observed_verdict and decision. The former records an observation. The latter expresses what the team intends to do with it. Add links to the real alert and evidence in your own system, but do not invent a scan commit identifier or timestamp if the available interface does not expose one. Record that limitation explicitly.

A record also needs a freshness rule. In this proposed policy, a relevant code or dependency change suspends the previous deferral until its evidence is reviewed again. That rule does not imply the preview will scan immediately. GitHub documents periodic scanning and says pushing code changes does not trigger a scan; during preview, users cannot request an on-demand scan. A prior verdict may consequently lag the code a reviewer is discussing. ^[2]

This is why a verdict should not become a release gate that pretends to inspect each proposed change. If a release decision requires evidence about the changed application now, establish an analysis or review process that can supply it. Mark the earlier verdict stale when the release review needs evidence about changed code.

What should the pilot enable first?#

Enable evidence collection in an intentionally small, representative scope. A repository administrator or other authorized role can configure reachability after Dependabot alerts are enabled. Organization and enterprise custom security configurations provide a way to apply settings at scale. Begin with an eligible repository whose maintainers can inspect the resulting alerts rather than starting with an organization-wide policy change. ^[3]

Before enabling the pilot, record its current alert workflow: who owns review, how fixes are verified, what qualifies for deferral and where unresolved alerts remain visible. This baseline makes the new signal assessable. Without it, a changed priority order may look like improvement even if alert ownership became less clear.

Choose a repository with enough real open alerts to inspect the available outcomes, but do not manufacture a vulnerable production dependency to produce a desired screenshot. If the initial sample contains only one verdict, record that coverage limit. Missing examples should remain untested branches, not become hypothetical successful results in a rollout report.

Use a custom security configuration only after understanding its existing settings and enforcement behavior. The configuration may cover more controls than reachability alone. GitHub also notes that an organization's default configuration applies automatically to newly created repositories, while transferred repositories require an appropriate configuration to be applied. An enablement inventory should therefore record actual repository coverage rather than assume a default proves it. ^[4]

The first operational review should inspect sample paths, unanswered cases and whether alerts remain in the ordinary queue. GitHub's review guidance explains how to navigate available call-path evidence and cautions that displayed paths are samples. A reviewer should trace the provided location into application behavior instead of assuming a diagram enumerates every possible route. ^[6]

When should the team stop or expand the pilot?#

Stop policy expansion when the team cannot explain unavailable results, cannot identify the evidence's freshness, or cannot keep deferred alerts assigned. These conditions do not mean the feature is defective. They mean the operating process is not yet ready to depend on it. Evidence collection can remain useful while policy changes wait.

For expansion, ask maintainers to review the same kinds of records using their normal security workflow. Did the call path help identify the owner? Did a potentially reachable result stay visible? Did a code change trigger re-review of a deferral? Did the team continue normal triage when analysis was unavailable? These are qualitative acceptance questions; this article claims no measured reduction in alert volume or review time.

Keep the preview's availability and usage terms in the rollout record, and recheck them before enabling a different repository or materially changing policy. This dated article does not promise a new check immediately before your deployment or report a future transition to general availability. If your decision depends on a fresh product guarantee, obtain that guarantee at decision time rather than infer it from an earlier announcement. ^[1][2]

There is also a useful counterexample to aggressive prioritization. A team operating under a fixed remediation requirement may be unable to defer an unreachable alert at all. Reachability can still help locate code and plan an upgrade, but it does not override that team's obligation. A tool's evidence and an organization's acceptable-risk policy are separate inputs.

The related license compliance rollout guide applies the same pilot discipline to a different product feature. It is not evidence that the two tools share availability or enforcement behavior. Each rollout needs its own eligibility, evidence and acceptance record.

What should preview users ask?#

Is Dependabot reachability generally available?

The announcement and documentation checked on 31 October 2026 describe a public preview. Verify current eligibility and terms when making an enablement decision. This article analyzes the dated preview and does not infer a later availability change. ^[1][2]

Does reachable mean an attacker can exploit the issue?

No. It means analysis found a call path to an affected function. Review inputs, execution conditions and exposure to assess practical exploitability. The call-path evidence is useful investigation material, while the remediation decision still needs application context. ^[2][6]

Can an unreachable alert be dismissed automatically?

Do not infer dismissal permission from that verdict. GitHub describes reachability as prioritization evidence and warns that results can change. Our proposed policy retains the alert, assigns an owner to any deferral and records what requires the evidence to be reviewed again. ^[2]

Will a push immediately refresh the verdict?

No. The preview documentation says pushing code does not trigger a scan and does not provide on-demand scanning. Treat a relevant change as a reason to question the previous evidence, and use another suitable review path when the decision cannot wait. ^[2]