I used to treat npm ci as the boring part of a job log, the stretch where you refill your coffee. Lately I read it differently, because that stretch is when a runner pulls code nobody on the team has looked at and runs its install scripts while the job's tokens are still loaded. GitHub's new package firewall is aimed at exactly that stretch.
GitHub put the firewall into public preview on October 20 for all GitHub Enterprise Cloud customers, including Enterprise Cloud with data residency. GitHub's reasoning will sound familiar to anyone who owns a pipeline: agents and CI runners install dependencies to finish a task or a build with no human in the loop, which makes them the easy target for malware that fires at install time.
A gate in the network path
The firewall sits between your endpoints (or your internal registries) and the upstream package repositories. Both metadata requests for package lists and the package downloads themselves flow through it, and it checks each one against policy before the install proceeds.
Administrators set that policy at the enterprise level. The controls available today are:
- a configurable cooldown period
- checks against the GitHub Advisory Database for malware or vulnerability advisories
- supply-chain checks such as attestation downgrades
If the firewall blocks a package by mistake, the user can request an exception through a workflow similar to other GitHub Advanced Security features. The service is free during the preview. At general availability GitHub plans to charge for it on metered usage, similar to Actions billing.
Right now it only supports npm.
Why the cooldown is the control I'd turn on first
I find the cooldown the most interesting control, because of how these attacks usually play out. A malicious version gets published, someone spots it, and the registry pulls it. A cooldown keeps brand-new versions away from your builds for a period you choose, so your runner doesn't have to be among the first machines to install them. You stop being an early adopter by default.
Pointing a runner at it
GitHub sends you to its docs page, Protecting endpoints with package firewall, for setup. The changelog doesn't give the endpoint format or the auth method, so take both from the docs. For npm, the change on the runner side comes down to a registry setting, roughly:
# values come from the setup docs; these are placeholders
npm config set registry "$PACKAGE_FIREWALL_URL"
npm ci
Before you trust it, check that installs really go through the firewall. Scoped registry settings in a committed .npmrc and the resolved URLs in a lockfile can both point npm somewhere you didn't expect. And if the runner can still reach the public registry directly, you have a gate with a gap beside it, so restrict egress where you can.
Where it gets awkward
A few things gave me pause:
- npm only. A polyglot repo with pip or Maven jobs is still installing those packages unchecked.
- A cooldown cuts both ways. If a dependency ships an urgent fix today, a long cooldown keeps that fix away from your builds too. Decide ahead of time how you'll handle that exception.
- A false positive now means a red build that waits on someone approving an exception. Find out who that is before the first Friday afternoon block.
- It's a preview, and GitHub says it is still scaling up the infrastructure behind it. Every install depends on it once you route through it, so watch your install times.
- Metered billing at GA means install volume becomes a cost line. Busy monorepos with lots of matrix jobs should get an estimate early.
Same idea, different layers
GitLab put its Dependency Firewall into early access for Premium and Ultimate. It works with GitLab's own registry and with external Nexus and Artifactory registries, and it covers npm, pip, Poetry, Maven, Gradle and Bundler. So it supports more ecosystems today, if you're on GitLab.
Teams already running a repository manager can apply similar policy at the proxy itself. Sonatype and JFrog both sell this kind of control for Nexus and Artifactory.
Closer to the client, pnpm (minimumReleaseAge) and Yarn (npmMinimalAgeGate) can hold back fresh versions on their own, with no proxy involved. Dependabot and Renovate have cooldown settings for update PRs as well. Those work one step earlier: they slow down the PRs that bump a version, but they don't stop a job from installing whatever a loose version range resolves to.
GitHub's version stands out mainly for where it sits: one enterprise-wide policy in front of every runner and coding agent you route through it. If you're already on Enterprise Cloud and mostly install npm packages, it costs you a registry setting to try during the free preview.
Next I'm watching for a second ecosystem. pip is the one I'd want, because a lot of my CI time goes to Python test jobs and none of them get this protection yet. If you've routed a busy pipeline through the preview, I'd like to hear what it did to your install times.
Top comments (0)