Guide · Supply-chain security · as of 29 October 2026
On 20 October 2026 GitHub put a firewall between your machines and the npm registry. It checks each package before it is installed, and blocks the ones that break a policy you set. Here is what it does, who can use it, what it will cost, and the one way teams get it wrong, from GitHub’s own announcement.
What it is
The package firewall sits between your endpoints, or an internal registry, and the upstream package repositories. Every request passes through it before anything is downloaded. It inspects both the metadata requests and the package downloads for signs of malicious activity, and refuses the ones that fail your policy. Nothing reaches a developer’s laptop, a CI runner or an AI coding agent until it has passed.
Who can use it, and what it costs
The policy controls available today
A configurable cooldown period: hold back a version for a set time after it is published, so a package that is poisoned and pulled within hours never reaches you. Checks against the GitHub Advisory Database for malware and known-vulnerability advisories, so a flagged package is stopped at the door. Supply-chain integrity checks such as attestation downgrades, where a package that used to ship signed provenance suddenly arrives without it. The firewall is only as strong as its policy. An administrator sets these at the enterprise level before it blocks anything.
When it blocks the wrong thing
A cooldown or a false positive will sometimes stop a package your build genuinely needs. When that happens the developer requests an exception, through a workflow like the ones other GitHub Advanced Security features use, and an administrator approves it. That is the trade: a short delay and the odd exception, in return for never installing the malware the delay was built to catch.
The one way teams get it wrong
It only protects the requests that go through it. Endpoints have to be configured to use the firewall instead of pointing straight at the public registry. The usual leaks: a scoped registry line in a committed .npmrc, a resolved URL baked into a lock file that downloads from somewhere else, or a runner that can still reach registry.npmjs.org directly. Close them, restrict what your runners can reach on the network, and confirm installs actually pass through the firewall.
Why GitHub built it now
The firewall is a direct answer to 2025 and 2026: the self-replicating Shai-Hulud worm, and the GhostAction campaign that swept malicious workflows through tens of thousands of repositories the day before this launched. The damage is done at install time, by code that runs before you ever use the package.
Where to go next
Why this matters to us
We are an AI lab in Dubai. The AI coding agents and business apps we build pull from npm every day, which is exactly the surface this firewall guards. We treat a dependency as untrusted until a cooldown, a lock file and a policy say otherwise.
Sources
read 29 October 2026
A question?
Tell us how your team ships, and we will tell you honestly where a dependency could bite it.