GitHub previews a package firewall that blocks npm malware before install

An npm package can steal credentials from a build runner before any of its JavaScript runs, through install scripts that fire the moment the dependency lands on disk. GitHub put a package firewall into public preview on 20 October that moves the check in front of that step, by sitting between npm and whichever endpoint pulled the package.

GitHub says in its Changelog post that the firewall is available for all GitHub Enterprise Cloud customers, including Enterprise Cloud with data residency, and that it is free during the preview. Only npm is supported today. When the service reaches general availability it will carry metered usage charges, in the same style as GitHub Actions billing.

What the firewall actually does

The post describes two parts. Administrators set policy at the enterprise level, with three controls named: a configurable cooldown period, checks against the GitHub Advisory Database for malware or vulnerability alerts, and supply-chain checks such as attestation downgrades. Endpoints then have to be configured to send their package requests through the firewall rather than straight at the upstream registry. GitHub names two kinds of endpoint it has in mind: GitHub Actions runners and coding agents.

Both metadata requests, meaning the lookups that resolve a package name to a version, and the package downloads themselves flow through the firewall, which evaluates them against the policy. If a package is blocked and the user believes the block was wrong, the request-an-exception workflow is the same one GitHub uses for other Advanced Security features.

The post does not state a target block rate, a false-positive rate, or any outcome from internal use. It also does not say when package managers beyond npm will be added, or what GA pricing will look like beyond the comparison to Actions billing.

Why the agent framing matters

GitHub names coding agents in the same sentence as CI/CD runners, which puts the firewall in the path of an unattended model installing a package it chose. The reader who runs a coding agent inside Enterprise Cloud now has an enterprise-level control that stops the agent reaching an unknown dependency without going through the policy, rather than relying on the agent to refuse.

The configurable cooldown period is the specific control that an agent would be most affected by. A typosquat or a freshly compromised package tends to be caught in hours or days, so a policy that refuses any version younger than a chosen window buys time for the advisory database to catch up. Changelog comments on previous supply-chain releases from GitHub, in the same category, point at the same idea.

A team on GitHub Enterprise Cloud that has not already configured a private registry mirror or an npm proxy can turn the firewall on without rebuilding its install path, because the firewall replaces the npm endpoint for the configured runner or agent rather than running beside it. A team on GitHub Enterprise Server will not see this feature until a future release names it, because the preview is Cloud only.

Source

GitHub package firewall in public preview, GitHub Changelog.