GitHub's package firewall checks npm installs for agents and CI before the code lands

GitHub has put a package firewall into public preview. It sits between your machines and the npm registry and checks each package download against your enterprise’s policy before it reaches the endpoint. The changelog went up on 20 October and GitHub rewrote it for clarity a day later.

GitHub’s reasoning is a “recent flood” of malware that strikes at install time. It says agents and CI runners are especially exposed, because they install dependencies “without a human in the loop.” The firewall checks both the metadata requests for package lists and the actual downloads.

Who can use it

• GitHub Enterprise Cloud customers, including Enterprise Cloud with data residency.
• npm packages only, for now.
• Free during the preview. At general availability it will be billed on metered usage, similar to Actions billing, with no price yet.

The five controls

Enterprise owners and security managers set these under the enterprise’s Policies, then Package firewall, per the setup docs:

Control	What it blocks	Default
Block known malware	Packages with an active malware advisory in the GitHub Advisory Database	On
Block vulnerability advisories	Versions with an advisory at or above a severity you pick	Critical only
Block attestation downgrades	Versions without SLSA attestations when earlier versions had them	On
Block newly-introduced install scripts	Packages that recently added preinstall or postinstall scripts	On
Minimum package age	Versions newer than a cooldown of 1 to 365 days (0 turns it off)	1 day

The last two target the pattern behind many recent npm attacks: a hijacked maintainer account pushes a fresh version with a new install script, and it gets pulled in within hours. A cooldown gives the ecosystem time to spot it first.

Pointing npm at it

Each enterprise gets its own registry URL. Put it in your user-level .npmrc, with a token from a user or bot account in the enterprise. The token needs no more than read-only access to public repositories:

registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}

Replace ENTERPRISE with your enterprise slug and keep the token in a CI secret, not in the repo. You can also route JFrog Artifactory through the firewall with a remote npm repository. GitHub labels that path experimental and says to drop any remotes that reach the public registry directly, or they bypass the firewall.

When it blocks something you need

A blocked install prints a link in the npm output or CI log to request an exception. The docs’ own example is a new version with a security fix that the age rule holds back. Enterprise admins and security managers review requests under Security and quality, then Package firewall bypass, and can allow one version or all of them. A custom role can carry the “Edit enterprise-level package firewall policy” permission if someone else should own the policy.

Practical takeaway

If you are on Enterprise Cloud, route one CI runner and your coding agents through the firewall first, keep the defaults, and read the block log for a week. Then decide on a longer cooldown and a stricter severity bar. If you are not on Enterprise Cloud, pinned lockfiles and a cooldown in your package manager, such as pnpm’s minimumReleaseAge, cover part of the same ground.