TL;DR: On October 20, 2026, GitHub put a package firewall into public preview. It sits between the machines that install packages, such as GitHub Actions runners, coding agents and developer laptops, and the public npm registry, and checks each request against a policy before anything is installed. It’s only for GitHub Enterprise Cloud customers, it’s free during the preview, and it supports npm only. If you’re not on Enterprise Cloud, you can copy its two most useful ideas today: a waiting period before new package versions install, and tighter control of install scripts.
What happened
GitHub’s changelog says attackers increasingly exploit “systems at package installation time, harvesting credentials on CI/CD hosts or developer workstations without even running the package’s code.” The firewall inspects “both metadata requests and package downloads” and blocks what fails the policy.
- Who gets it: GitHub Enterprise Cloud customers, including Enterprise Cloud with data residency.
- Price: free during the preview. At general availability, GitHub says it “will be charged based on metered usage, similar to Actions billing.”
- Scope: “Currently the package firewall only supports npm packages.”
What the firewall checks
According to GitHub’s setup docs, enterprise admins can set five controls:
- Block known malware (on by default): blocks packages with an active malware advisory in the GitHub Advisory Database.
- Block vulnerability advisories (default: Critical only): you can widen it to High, Medium or any severity.
- Block attestation downgrades (on by default): if earlier versions shipped with SLSA attestations and the requested version doesn’t, the download is blocked. GitHub notes that missing attestations “can indicate a compromised publishing process.”
- Block newly-introduced install scripts (on by default): catches packages that recently added scripts such as
preinstallorpostinstall, which GitHub says “can run arbitrary commands on your system and can be used to steal credentials.” - Minimum package age (default 1 day): a cooldown you can set from 1 to 365 days, or 0 to turn off, so brand-new versions don’t install before problems have time to surface.
Nothing changes until you point your machines at it. Each enterprise gets its own registry URL, set in the user-level .npmrc along with a GitHub token from a member of the enterprise. GitHub says to store that token “in a CI secret” and not commit it to a repository. If a package is blocked by mistake, users can request an exception, with a workflow GitHub compares to its other Advanced Security features.
Why it matters
In our view, two things make this pressing for small teams:
- Agents install packages without asking. A coding agent running
npm installin CI or a sandbox is exactly what an install-time attack is built for, and it often holds tokens. - Fresh versions carry the most risk. A short wait before installing new releases is one of the cheapest defenses there is, and it’s the idea behind the firewall’s 1-day default.
Most small businesses and indie builders aren’t on Enterprise Cloud. But the package managers themselves can do part of the job.
What to do
If you’re on GitHub Enterprise Cloud: try the preview in one CI pipeline first. Keep the defaults, then decide whether to block more than critical vulnerabilities. Decide who will review exception requests, because a cooldown can also hold back a brand-new security fix.
If you’re not, set a cooldown in your package manager. The units differ by tool:
| Tool | Setting | Unit | Default |
|---|---|---|---|
| npm | min-release-age (in .npmrc) |
days | off (null) |
| pnpm | minimumReleaseAge (in pnpm-workspace.yaml) |
minutes | 1440 (one day) since pnpm 11; 0 before |
| Bun | minimumReleaseAge under [install] (in bunfig.toml) |
seconds | off (null) |
So a one-day wait is min-release-age=1 in npm, minimumReleaseAge: 1440 in pnpm and minimumReleaseAge = 86400 in Bun. If you’re on pnpm 11 or later, you already have a one-day cooldown unless someone turned it off.
Leave room for urgent fixes. npm’s docs say that when the age window blocks a patched version, npm audit fix keeps the vulnerable version, warns, and exits with a non-zero code. Use min-release-age-exclude (npm), minimumReleaseAgeExclude (pnpm) or minimumReleaseAgeExcludes (Bun) for a package you need right away. npm and pnpm also accept a pattern for your own scope, such as @myorg/*; Bun takes package names or exact versions.
Control install scripts. npm has ignore-scripts, which tells npm not to run the scripts in package.json files, your own included, and an allowScripts policy in package.json; setting strict-allow-scripts=true turns unreviewed install scripts into a hard error. In pnpm, allowBuilds lists which packages may run build scripts, and strictDepBuilds, on by default, makes the install fail when a dependency has unreviewed ones.
Know what Dependabot already does. GitHub’s docs say Dependabot applies a default 3-day cooldown to version updates even if you never set cooldown. That default doesn’t apply to security updates.
Give agents less to steal. Whatever an agent can read during an install, a malicious script can read too. Use short-lived, narrowly scoped tokens in agent and CI environments, and keep scans running with the free npm audit and Dependabot alerts. For a recent example of what’s at stake, see our story on the OpenCode Console security breach.
What we don’t know yet
GitHub hasn’t published general-availability pricing beyond “metered usage,” and hasn’t given a date for package types beyond npm. We haven’t tested the firewall ourselves.
If agents open pull requests in your repositories, our story on Claude Code Review covers another layer of checks.
Sources & method
Sources
- GitHub Changelog, “GitHub package firewall in public preview,” Oct 20, 2026
- GitHub Docs, “Protecting endpoints with GitHub package firewall”
- npm Docs, config
- pnpm Docs, dependency resolution settings
- pnpm Docs, build settings
- Bun Docs, bunfig.toml
- GitHub Docs, Dependabot options reference
Method. Last checked October 21, 2026, at about 10:25 a.m. Manila time (02:25 UTC). Availability, pricing, scope and quotes come from GitHub’s changelog; the five controls, defaults, registry setup and token advice come from GitHub’s setup docs. The package-manager settings, units and defaults come from npm, pnpm and Bun docs, and the Dependabot default from GitHub’s Dependabot reference. The “why it matters” points are our own judgment. No affiliate links on this page. How we work.
Spotted an error? See our corrections policy and tell us.
