GitHub npm Package Firewall: How It Blocks Malicious npm Packages at Install Time, and How to Set It Up
GitHub's new package firewall checks npm packages before they install and blocks known malware, risky versions and brand-new releases. Here is what is confirmed, who can use it and how to set it up this week.
Where Worldwide
On this page 8 sections
GitHub has released a package firewall, in public preview since October 20, 2026. It checks npm packages before they install and blocks any that match known malware, serious vulnerabilities or other warning signs. If your business builds websites or apps with JavaScript, this is a rare control that stops a bad dependency before it reaches a developer laptop, a build server or an AI coding agent.
What GitHub announced
GitHub's changelog describes the package firewall as a service that sits between your machines and the public package registries. It inspects both the metadata requests and the package downloads for signs of malicious activity, and it blocks anything that breaks your policy. GitHub says agents and CI runners are especially exposed, because they install dependencies with no person reviewing what comes in.
An editor's note dated October 21, 2026 says the post was rewritten for clarity. The facts below come from that changelog and GitHub's setup documentation.
What is confirmed and what is not
Confirmed by GitHub:
- It is in public preview for all GitHub Enterprise Cloud customers, including data-resident Enterprise Cloud.
- For now it only covers npm packages. Both the changelog and the exception request form in the docs say npm is the only supported ecosystem.
- It is free during the preview. At general availability, GitHub says it will bill on metered usage, similar to Actions billing.
- Enterprise administrators and security managers set the policy. If a package is blocked by mistake, users can request an exception.
- Artifactory support exists but GitHub labels it experimental.
Not known yet:
- No general availability date and no published prices.
- GitHub has not published detection or false-block rates, and we found no independent testing of the service.
- There is no timeline for other ecosystems such as PyPI, Maven or NuGet.
- The announcement only names Enterprise Cloud. It does not say whether other GitHub plans will get access.
One point is clear from how it works: the firewall only protects machines that send their npm traffic through it. Any build or laptop still pulling straight from the public registry is not covered.
How the npm package firewall works
You set the controls under your enterprise, in Policies, then Package firewall. GitHub's documentation lists five controls:
| 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 vulnerabilities at or above a severity you choose | Critical only |
| Block attestation downgrades | A version with no SLSA attestation when earlier versions had one | On |
| Block newly-introduced install scripts | Versions that newly add scripts such as preinstall or postinstall | On |
| Minimum package age | Versions published more recently than the age you set (1 to 365 days, or 0 to turn off) | 1 day |
The last three controls matter most against new attacks. A hijacked package is often caught within hours or days, so a waiting period means your builds skip the riskiest window. And install scripts are a common way malicious packages run code the moment someone types npm install.
Why malicious npm packages matter to a business
One npm install can pull in hundreds of packages written by people you have never vetted. Install scripts run with the same access as the person or server running them. On a developer laptop, that can mean SSH keys and saved logins. On a build server, it can mean deploy keys, cloud credentials and the code you ship to customers.
That is why supply chain attacks hit businesses that never wrote a line of bad code themselves. If a poisoned package makes it into your website build, your customers' browsers run it. AI coding agents add to the risk, because they add and install dependencies quickly and no one checks each choice. A gate at install time gives you a check that does not depend on someone noticing in the moment.
How to set up the GitHub package firewall this week
| Step | How | How to check |
|---|---|---|
| 1. Confirm your plan | The preview is for GitHub Enterprise Cloud | Your organization belongs to an enterprise account |
| 2. Set the policy | Enterprise, Policies, Package firewall. Review each default, and consider a longer minimum package age for production builds | The policy page shows your chosen settings |
| 3. Create a token | Use a user or bot account that is a member of the enterprise. GitHub says the token only needs read-only access to public repositories | The token is stored as a CI secret, never committed |
| 4. Point npm at the firewall | Add the registry and token lines below to the user-level .npmrc on each runner and laptop | Run npm config get registry and confirm it shows the firewall URL |
| 5. Close the bypasses | Look for project .npmrc files, --registry flags, Dockerfiles and agent environments that still point at the public registry. In Artifactory, remove public npm remotes from the virtual repository, as GitHub's docs instruct | Every build log shows downloads coming through the firewall |
| 6. Name your approvers | Requests appear under Security and quality, then Package firewall bypass | Someone owns the queue so blocked builds are not left waiting |
GitHub's documented .npmrc lines, with ENTERPRISE replaced by your enterprise slug:
registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}
When a package is blocked, the npm output or CI log includes a link to request an exception. The request asks for the repository, ecosystem, package name, version and a reason. Approved exceptions are added to the policy and can be removed later under Package overrides.
If you are not on GitHub Enterprise Cloud
You can still cut the same risks without the firewall:
- Commit your lockfile and use npm ci in builds, so builds install only the versions you have already reviewed.
- Treat new install scripts in a dependency update as a red flag, and use npm's --ignore-scripts option where your build allows it.
- Give build servers only the credentials they need, so one bad package cannot reach everything.
- Review dependency updates before you merge them, especially ones that are only hours old.
If your builds run on your own servers, our self-hosting infrastructure work covers locking down runners and registries.
npm package firewall questions people are asking
What is the GitHub package firewall?
It is a GitHub service that sits between your machines and the npm registry. It checks each package against your enterprise's policy and blocks downloads that fail it.
Is the GitHub npm firewall free?
Yes, for now. GitHub says it is free during the preview and will move to metered billing at general availability. GitHub has not published prices.
Who can use it?
GitHub Enterprise Cloud customers, including data-resident Enterprise Cloud. Administrators and security managers configure it.
Does it work for Python, Java or .NET packages?
Not yet. It only supports npm, and GitHub has not given a timeline for other ecosystems.
Does it work with yarn or pnpm?
GitHub's setup guide only covers the npm command line and Artifactory. Other clients are not documented, so test them before you rely on the firewall.
What happens if it blocks a package we need?
The error includes a link to request an exception. An administrator or security manager reviews it and can allow that version or all versions.
Does it replace Dependabot?
No. Dependabot alerts you about vulnerable dependencies already in your code. The firewall stops a risky download at install time. They work well together.
The bigger lesson
Your code is only as safe as the packages it pulls in, and those decisions now happen in build servers and AI agents with no one watching. A gate that checks every install is worth having, but it only works if every machine goes through it. Map where your installs happen first, then close every path around the gate.
Want help setting this up? See our security hardening services or request a quote.
Get security alerts like this by email, plus our free checklist, at /security-alerts.
Sources: GitHub Changelog: GitHub package firewall in public preview; GitHub Docs: Protecting endpoints with package firewall.
Have a question about this article?
Ask it here and we will answer you directly by email. Questions are private, never posted.
Security alerts by email
Hear about the next one first.
When attackers start using a flaw in software businesses run on, we email what it is, whether it touches you and what to do that week, with a round-up of our latest security writing. Free, one-click unsubscribe. You get the checklist straight away: 12 things to secure this week.
Want a result like this?
Security alerts, breaches and the technology a business runs on: what happened, who it affects and what to do.
Get a Tech QuoteKeep reading
Rosstat Cyberattack: Russia's Statistics Agency Is Still Restoring Systems, What Is Confirmed and What Businesses Should Check
Rosstat says it is still restoring systems after cyberattacks from October 29 to November 1, 2026. Hackers cla...
Ransomware Business Continuity: Why Backups Alone Won't Keep Your Company Running, and What to Do This Week
Backups can bring systems back, but they do not keep work moving during the outage. Here is what Japan's IPA l...
Sshole SSH Vulnerability (CVE-2026-123158): Exploit Attempts Hit Honeypots, Which Alpine Linux Servers Are Exposed, and the Fixed Versions to Install
An OpenSSH flaw called Sshole can let attackers skip the password on some Alpine Linux servers, and honeypots...
