What happened
GitHub released the npm package firewall in public preview on October 20, 2026. On October 28, 2026, GitHub released Dependabot reachability analysis in public preview for eligible GitHub Enterprise Cloud repositories. The new capability uses curated vulnerable-function data and CodeQL call graphs to determine whether application code has a path to the affected function in a dependency.
The reachability preview supports JavaScript and TypeScript repositories with npm, Yarn or pnpm lockfiles on GitHub Enterprise Cloud. GitHub reports four verdict categories for dependency reachability. The listed verdicts are Reachable, Potentially reachable, Unreachable and Reachability unavailable. Potentially reachable findings should be treated as reachable, while unavailable findings remain subject to normal triage. Verdicts do not automatically close or dismiss Dependabot alerts.
Reachability analysis is off by default, begins after enablement and reruns daily while a repository has open Dependabot alerts. The preview uses GitHub-hosted runners and does not support self-hosted runners. When analysis exceeds three hours, it may return Reachability unavailable. GitHub’s package firewall is a separate public preview for GitHub Enterprise Cloud and currently supports npm packages only.
No incident indicators, victim data or threat-actor artefacts were published because this is a product-control release rather than an incident disclosure. Attribution posture: This is a product-control release, not an incident; neither GitHub nor the reporting source attributes malicious activity to a named actor.
Why this matters now
Dependency programmes often treat package presence and exploitability as the same condition. Reachability analysis adds call-path evidence, enabling teams to concentrate remediation where application code can invoke the vulnerable function. That can reduce noise, but only if verdicts are governed carefully and unavailable or uncertain analysis does not become an unreviewed exception.
The preview is materially constrained. It covers JavaScript and TypeScript repositories with npm, Yarn or pnpm lockfiles on GitHub Enterprise Cloud, runs on GitHub-hosted infrastructure and can return unavailable results for unsupported or long-running analysis. Enterprises with self-hosted-runner requirements, complex monorepos or other ecosystems cannot treat the release as a universal dependency-risk control.
GitHub’s earlier npm package firewall adds an install-time policy gate, including configurable cooldowns and checks for malware, critical vulnerabilities and attestation downgrades. Together, the controls create two different decisions: whether a package version may enter the environment and how urgently an existing vulnerable dependency must be remediated. Security leaders should keep those policies separate and auditable.
The decision for security leaders
Pilot the feature where alert volume impedes timely remediation, but preserve existing severity, exploitability, production context and asset-criticality inputs. Reachability is evidence about a call path, not a complete likelihood or impact assessment. A reachable low-impact issue and an unreachable high-consequence issue may still require different decisions.
Approve an explicit verdict policy before broad enablement. Treat Reachable as prioritised technical exposure, Potentially reachable as requiring the same urgency until resolved, Unreachable as a candidate for time-bound deferral, and Reachability unavailable as normal manual triage. Do not permit automated dismissal during the preview.
Govern the package firewall as a separate supply-chain admission control. Set cooldown and exception rules according to release criticality, emergency patch requirements and build availability. Record who can approve bypasses, how long exceptions last and what evidence is required when a newly published package must enter production immediately.
Evidence of closure
- A pilot report records eligible repositories, analysed alerts, unavailable results and remediation outcomes.
- The approved verdict policy defines ownership, deadlines and exception treatment for all four verdicts.
- Deferred Unreachable findings have documented expiry dates and compensating evidence.
- Package-firewall exceptions identify the package, approver, rationale, duration and validation result.
The Security.io assessment
The October 28 release is useful because it can move dependency management from inventory-only prioritisation toward evidence of executable call paths. Its value is strongest for organisations with large JavaScript estates and alert backlogs, not as a universal replacement for software composition analysis or exploit intelligence.
The preview limitations are decision-relevant. Unsupported languages, self-hosted runners, complex repositories and unavailable analyses create uneven assurance. Security leadership should measure coverage before claiming programme-level improvement and should retain a visible queue for alerts that the feature cannot analyse.
The central control uses CodeQL call graphs to identify paths from application code to vulnerable dependency functions; no offensive AI-enabled agent is involved. No AI-enabled agent or framework is central to the reachability-analysis decision. No underlying AI model was identified for the reachability-analysis mechanism. No AI operator configuration applies to the central control described in this story.
Questions for the morning meeting
- Which JavaScript and TypeScript repositories have enough alert volume to justify an immediate reachability pilot?
- Who approves treatment of potentially reachable, unreachable and unavailable verdicts?
- Can teams prove that lower-priority findings remain tracked rather than silently dismissed?