Ing. Calogero Bono
On October 20, 2026, GitHub unveiled the package firewall, a filter that sits between the computers that install packages and the public registries they download from. Today it is in public preview for all GitHub Enterprise Cloud customers and supports only npm. The goal is to stop malware that strikes at install time, a risk that is greater for AI agents and build systems that install dependencies with nobody watching. If you develop software or manage those who do, it is a signal of where software supply chain security is heading.
A few terms before we get into the facts. A registro (or registry) is the online repository from which packages are downloaded, such as npm for JavaScript. A dipendenza is a piece of someone else's code that your project uses. CI/CD are the automated procedures that build and publish software. A SLSA attestation is a verifiable statement about how and by whom a package was built. Metadati (metadata) is information about a package, for example the list of available versions.
What is GitHub's package firewall?
According to the official GitHub changelog, recently there has been a real wave of malware attacks that exploit the moment packages are installed. Agents and CI runners are particular targets, because they install dependencies to complete a task or a build without a person in the loop.
The firewall sits between endpoints, or internal registries, and upstream package repositories. As The Hacker News reports, GitHub describes it this way. "The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate," that is, a gate of rules applied at installation time.
The issue is not theoretical. The Register reported on a campaign in which attackers reportedly turned GitHub issues into a supply chain attack against 61 public repositories in less than an hour. The page available to us offers no further details, so we cannot say whether and how the two stories are connected.
How does it work and what controls does it offer?
The flow has two steps. First, administrators set the rules for their enterprise. Then coding agents and CI/CD hosts point to the firewall instead of directly to public registries. Both metadata requests and downloads pass through the firewall, which evaluates them against the policy.
Available controls
From The Hacker News list, these controls emerge.
- Blocking known malware, by checking active advisories in the GitHub Advisory Database.
- Blocking by vulnerability severity, again via the database. The default blocks only the "Critical only" level, but you can choose "High or higher", "Medium or higher" or "Any severity".
- Blocking attestation downgrades. The firewall compares the attestations of the requested version with those of earlier versions and stops the download if the SLSA attestation is missing.
- Blocking new installation scripts, that is, those that run through preinstall or postinstall hooks and can be used to steal sensitive data.
- Cooldown period, which prevents installing versions newer than the configured minimum age.
The cooldown can range from 1 to 365 days. The default is 1 day and it is disabled by setting it to 0.
What if it blocks a legitimate package?
If a package is blocked by mistake, the user can request an exception. For GitHub, the process is similar to that of other GitHub Advanced Security features. According to The Hacker News, the request can be approved by enterprise administrators and security managers.
How much does it cost and who can use it?
The service is available in public preview for all GitHub Enterprise Cloud customers, including the version with data residency. During the preview it is free. When general availability arrives, GitHub says it will be paid based on measured usage, similar to Actions billing.
GitHub explains that the preview is meant to scale the infrastructure and add features based on customer requests. For configuration instructions, it refers to the documentation Protecting endpoints with package firewall.
Why is there so much talk about waiting periods?
The cooldown is the simplest and perhaps most widespread rule. The Hacker News notes that over the past year similar waiting periods have been introduced in npm, Python, Visual Studio Code, Ruby, Bun, pnpm and Yarn. The principle is to reduce the chance that a freshly published, unreviewed version ends up in a build right away.
It helps especially against those who take over a maintainer's account and publish a poisoned version of a popular package. The wait slows rapid spread, whether manual or automated.
The same article notes that Rust 1.100, due out on November 12, 2026, should add a configurable minimum publish age for crates. The option is called "global-min-publish-age" and lives in the cargo/config.toml file. If not specified, a default wait of seven days applies.
On the flip side, Socket, cited by The Hacker News, speaks up. "The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception," the company says. It adds that a release that slipped past checks can simply survive the cooldown. The value, according to Socket, lies in giving researchers, maintainers and registries time to act.
Limits to know
- Today the firewall supports only npm. If you work with PHP, Python or other ecosystems you are not covered, and the sources give no dates for other registries.
- It is reserved for GitHub Enterprise Cloud customers. The sources say nothing about smaller plans.
- We are in preview. Features, infrastructure and pricing may change, and the usage-based cost is not yet quantified.
- We have no independent data on effectiveness. The sources report GitHub's claims, not tests on real malware, and no false positive figures are given.
- As Socket points out, the cooldown does not make malicious code harmless. An undetected version can stay hidden beyond the waiting period.
What changes for those who work in digital
The practical point is that security shifts from checking after the fact to checking before installation. For those who develop with AI agents that write and install on their own, this means having a central rule instead of trusting each individual agent. If you use AI-guided development tools, it is worth rereading the risks we described in our article on vibe coding for SMEs.
For Italian companies the topic also touches compliance. The software supply chain is part of what we cover in the guide to the NIS2 supplier register. Being able to show that packages pass through a filter with written rules is a concrete argument, although no source links the firewall to NIS2.
Anyone who uses a lot of open source should remember that every dependency is a supplier. We cover this in our in-depth piece on open source in business. Even those who are not Enterprise customers can borrow the idea with tools already available, for example the waiting periods some package managers offer.
For build and production servers, updates and isolation also matter. If you want infrastructure managed by others, there is our hosting and managed servers service. If you are instead evaluating a custom project, you will find the path in custom software development.
Our take
The idea is sound. Stopping a package before it runs on the computer is more effective than noticing afterward, and doing it at a single point avoids relying on the discipline of every developer or every agent. The fact that GitHub starts precisely with unsupervised agents seems to us an honest reading of the problem.
We have two reservations. The first is commercial. Such a useful protection, for now reserved for the Enterprise tier and billed by usage after the preview, risks leaving small teams exposed, and they are often the most vulnerable. The second is technical. Many controls rely on GitHub's database and on time, and time is no guarantee, as Socket itself admits.
For this reason we do not see it as a definitive shield. It is one more layer, useful if combined with dependency review, version pinning and minimal permissions for agents. If you think turning on the firewall is enough, you are giving yourself false security.
Frequently asked questions
Is GitHub's package firewall free?
Yes, but only during the preview. GitHub says that at general availability it will be charged based on measured usage, similar to Actions. Prices are not yet announced.
Does it only work with npm?
Yes, for now it supports only npm packages. The sources announce no dates for other ecosystems. If you use other languages, you will need other defenses for the time being.
Who can use it?
All GitHub Enterprise Cloud customers, including the version with data residency. The sources mention no other plans. Administrators configure the rules for the entire enterprise.
What happens if it blocks a legitimate package?
The user can request an exception. According to The Hacker News, the request can be approved by administrators and security managers. The process, GitHub says, is similar to that of other Advanced Security features.
Is a waiting period enough to stop malware?
No. It helps buy time against freshly published versions, but Socket points out that malicious code does not become harmless with age. An undetected release can get past the waiting period.
What to watch until general availability
In the coming months it is worth following three things. The usage-based price GitHub will set, any extension beyond npm, and the arrival of the minimum age in Rust 1.100, expected on November 12, 2026. In the meantime you can act as follows.
- List the dependencies used by CI and agents, and decide who can install what without supervision.
- Evaluate a waiting period on new versions, knowing it also delays legitimate fixes.
- Prepare a procedure for exceptions, with a manager who approves quickly but with a written record.
