AI Security

GitHub just put a firewall in front of npm. When the registry owner sells the gate, what’s left for everyone else?

Coding agents and CI runners install packages with no human watching. GitHub’s new package firewall checks every npm download against policy first. It’s free in preview and lands on turf Sonatype, JFrog and Socket have worked for years.

Oct 29, 2026 · 4 min read

What shipped. GitHub launched a package firewall in public preview for GitHub Enterprise Cloud customers. It sits between your machines and the public npm registry. Laptops, CI runners (the servers that build your code) and coding agents ask the firewall for packages instead of going straight to npm. The firewall checks each request against your policy and blocks what fails. It’s free during the preview. At general availability, GitHub says it will be billed on metered usage, like Actions. Today it covers npm only.

The five rules. Admins get five controls. Block known malware using the GitHub Advisory Database, on by default. Block versions with known vulnerabilities, defaulting to critical only. Block “attestation downgrades”: if earlier versions came with a signed record of how they were built and the new one doesn’t, that’s a red flag that the publishing process was hijacked. Block newly added install scripts, the preinstall and postinstall hooks that run code the moment a package lands. And a minimum package age, or cooldown: refuse any version younger than 1 to 365 days. The default is one day.

Why now: nobody is watching the install. GitHub’s own framing is blunt. Agents and CI runners “install dependencies to accomplish a task or complete a build without a human in the loop.” A developer might pause at a weird package name. An agent won’t. We’ve already seen what that speed does. In September 2025, CISA warned about Shai-Hulud, a self-replicating npm worm that compromised more than 500 packages, stole tokens and cloud credentials, and used stolen npm tokens to publish more infected versions. Unit 42 reported that later variants ran through preinstall scripts. Look at GitHub’s rule list again. Two of the five map straight onto that playbook.

The boring control that does the work. The cooldown sounds dull. It might be the most valuable rule here. The logic: when a maintainer account gets hijacked, someone usually notices. A waiting period gives researchers, maintainers and the registry time to pull the bad version before it reaches you. The idea is spreading fast. The Hacker News lists cooldowns landing across npm, Python, VS Code, Ruby, Bun, pnpm and Yarn, and Rust 1.100, due Nov. 12, adds a seven-day default. Socket, which sells supply-chain detection, named the catch: legitimate fixes wait too, and malicious code “doesn’t magically become harmless with age.” A cooldown is a speed bump, not a scanner.

Platform versus best-of-breed. This gate isn’t new. Sonatype has sold a repository firewall for years. JFrog Curation blocks malicious packages before they reach your Artifactory. Socket built its business on spotting malicious packages by behavior. What’s new is who’s selling it. GitHub has run npm since 2020, and GitHub is owned by Microsoft. The registry owner now sells the checkpoint in front of its own registry, free for now, inside a console most enterprises already pay for.

GitHub has a real structural edge. It sees the publish side. It knows when a maintainer’s release suddenly loses its build attestation or sprouts an install script, because the release happened on its infrastructure. A third-party proxy has to infer that from the outside.

Where the specialists still win. Three gaps. First, coverage: npm only, while most enterprises also pull from PyPI, Maven and others. Second, detection depth: the malware rule relies on GitHub’s advisory list, and a brand-new malicious package has no advisory yet. That’s exactly the window the cooldown is meant to cover, and why it’s a blunt tool. Third, independence: some buyers won’t want the registry operator as the only judge of the registry.

My take. For a GitHub Enterprise shop that mostly ships JavaScript, “good enough and already in the contract” will win a lot of deals. The best-of-breed pitch now has to be specific: what do you catch in the first 24 hours, before any advisory exists, across every ecosystem we use? Vendors who can show that with data keep their seat. Vendors whose value was “we proxy npm and check a list” just got commoditized.

What I’d do this week. Point CI runners and agent sandboxes at the firewall first. They install the most and watch the least. Set a longer cooldown there than on developer laptops, and keep a fast exception path for urgent patches. Remember the firewall needs a GitHub token on every endpoint. That’s a new secret in your build system. Keep it read-only, store it in your CI secret store, and rotate it like any other credential.

Sources