GitHub puts a firewall between your CI runners and the npm registry
On October 20, 2026, GitHub opened a public preview of a firewall that sits between Actions runners, coding agents and the npm registry, inspecting metadata requests and package downloads alike. It blocks malware at install time, where scanners show up too late: turn it on if your CI installs third-party code.
October 20, 2026. GitHub opened its package firewall in public preview for all GitHub Enterprise Cloud customers, including data-resident deployments. The service sits between endpoints — Actions runners and coding agents — and the upstream package registries, and it only inspects npm for now. Why it matters: package attacks no longer depend on your application actually running malicious code. A postinstall script can harvest credentials from a CI/CD host before any line of the package meaningfully executes — that window, the download and the install, is exactly what the firewall closes. It arrives at the right moment: package-install malware has become the default first stage of supply-chain attacks against CI pipelines.
Install time became the execution moment
The problem statement is dated and quantified. GitHub describes “an increasing number of malware attacks” that exploit systems at package installation time, harvesting credentials on CI/CD hosts or developer workstations “without even running the package’s code.” In other words, the attacker no longer needs a vulnerable application to load their code — they just need an npm install to run on a machine that holds secrets.
That shift changes the geometry of every defense you already run. A vulnerability scanner — Dependabot, a SAST tool, a SCA analysis — looks at code after the download, and often after merge. The damage has already been done while you scroll: the install hook ran during npm install, before any alert could be generated. That is the gap GitHub is aiming to close by moving the boundary to the install point itself.
A firewall, not a scanner
The difference in kind is the heart of the announcement. The package firewall does not scan a repository: it interposes itself between the endpoint and the registry, inspecting both metadata requests and package downloads for signs of malicious activity. It is an inspection proxy, not a retrospective report.
Setup breaks into three steps. First, an administrator defines policy controls: a configurable cooldown period, checks against the GitHub Advisory Database for malware or vulnerability alerts, and supply-chain checks such as attestation downgrades. Second, endpoints — Actions runners or coding agents — are configured to route their requests through the firewall instead of pointing straight at the upstream registry. Third, every request and every download is evaluated against the policy, with an exception workflow modeled on other GitHub Advanced Security features when a package is blocked in error.
Two limits are worth knowing before you get excited. The service only supports npm today — no PyPI, no Maven, no containers. And it is restricted to GitHub Enterprise Cloud; free and Team plans are out. The service is free during the preview, then billed on metered usage, “similar to Actions billing,” once it reaches general availability.
The window your scanner never sees
To see what this firewall actually changes, look at the incidents the ecosystem already absorbed this year. The MALFEX campaign hid a shellcode loader inside a native npm addon that stayed live — an episode we covered — and CrowdSec suffered a supply-chain compromise through a hijacked npm package. The common thread is the same: the malicious package is downloaded and installed before the community flags it, and every defense built on post-download scanning arrives late.
The package firewall inverts that order. Sitting in the inspection path between the runner and the registry, it sees the metadata request and the downloaded binary as they move — which lets it cut the install off before the postinstall runs. It is the first npm defense from GitHub that operates inside the install flow rather than the code-review cycle.
The configurable cooldown deserves particular attention. It encodes a simple policy: refuse to install a package published fewer than N hours ago, giving reputation sources and the Advisory Database time to catch up. It is a blunt heuristic, but it targets the dominant profile of typosquatting and freshly-published-package attacks, which live and die in a matter of hours.
Where it slots into the stack
The package firewall replaces none of the existing pieces: it adds a layer at a specific level. Dependabot keeps driving versions and vulnerability alerts; version pinning (lockfiles) and SLSA or sigstore attestations keep proving provenance; the firewall intercepts the install flow itself. Its value is positional: it sees the package the moment it becomes executable, not the moment it is reviewed in a pull request.
That position carries an operational cost worth planning for. Routing traffic through an inspection proxy means changing the egress network of runners and agents — they can no longer point straight at registry.npmjs.org. On self-hosted runners or distributed coding agents, this is a question of routing and trust: the firewall becomes a single point of passage, and therefore a potential single point of failure. Teams that already lock down egress with an allowlist must add the firewall address, and provision its high availability before forcing it onto CI.
One angle is easy to overlook: the firewall explicitly names coding agents alongside CI runners as protected endpoints. That is a quiet but significant admission — as agents are increasingly handed credentials to install dependencies directly, they become install-time attack surface in their own right. A firewall that sits in front of both closes the same gap twice: once for the pipeline, once for the autonomous coder.
What to do
The playbook is short, and for eligible teams it is a few minutes of work.
- If you are on Enterprise Cloud and your runners or agents run
npm install, turn the firewall on now — it is free in preview and the setup cost is low. - Route your endpoints through the firewall. This is not a single checkbox: each runner or agent must point at the firewall instead of the upstream registry. Plan the cutover on runner images and coding-agent flows.
- Measure before you lock down. Start in an observe mode, list packages blocked in error, then tighten the policy and the cooldown.
- Do not hand everything to the firewall. It covers npm, not the rest: keep Dependabot, attestation verification and version pinning for other registries and for code review.
Confirm your organization’s plan, then follow the setup procedure.
# A freshly published package is the classic typosquatting profile.
# The package firewall cooldown blocks the install before postinstall runs.
npm view <package> time.created # publication age, to cross-check against your cooldownVerdict
If you run Actions runners or coding agents that install npm packages on Enterprise Cloud, enable the firewall today: it is free, and it closes a window — install time — that your current scanners do not cover. If you are off Enterprise Cloud, or your critical dependency lives outside npm, treat it as a direction signal rather than a fix: the supply-chain boundary is moving toward the install point, and teams that do not prepare will keep discovering malicious packages after the fact.