GitHub Launches npm Firewall to Stop Malicious Packages Before Installation
Translated by a model; the original is in Russian.
GitHub has announced a package firewall designed to stop suspicious npm packages at installation time. According to the company, the firewall "inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate."
For now, only npm is supported. The feature is available in public preview to all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.
How it works
The firewall sits between endpoints or internal registries and the upstream package repositories. Its goal is to defend against attacks that compromise systems the moment a package is installed. The risk is especially high when AI agents and CI runners install dependencies automatically, without the user's explicit permission, to complete a task or a build.
The idea is that coding agents and CI/CD hosts route their requests through the firewall instead of pointing directly at public registries. The firewall checks downloads against configured policies and blocks those that fail them.
Administrators can configure the following controls:
- block known malware based on active advisories in the GitHub Advisory Database;
- block by vulnerability severity in the requested package version; by default only critical flaws block installation, but users can choose "High or higher," "Medium or higher," or "Any severity";
- block attestation downgrades — the download is stopped if the requested version lacks an SLSA attestation that earlier versions had;
- block newly introduced install scripts that run via preinstall or postinstall hooks, which can be abused to steal sensitive data;
- cooldown period — versions newer than a configured minimum age cannot be installed: from 1 to 365 days, defaulting to 1 day; setting it to 0 disables the rule.
If the firewall wrongly blocks a needed package, users can submit an exception request, which enterprise administrators and security managers can approve.
The industry takes a pause
Meanwhile, Rust 1.100, scheduled for release on November 12, 2026, will add a configurable minimum publish age for crates. The global-min-publish-age option in cargo/config.toml sets it in days or weeks; if left unspecified, a seven-day waiting period applies by default.
Over the past year, similar cooldowns have appeared in npm, Python, Visual Studio Code, Ruby, Bun, pnpm, and Yarn. They add friction to attacks in which someone hijacks a maintainer account and publishes a poisoned version of a popular package, counting on it spreading quickly.
Socket points out the downside: legitimate fixes have to wait too, unless developers make an exception. And malicious code does not become harmless with age — a release that escapes detection can simply outlast the cooldown. The value lies in buying researchers, maintainers, and registries time to act before the next dependency update carries an attack further.
Source: The Hacker News
Comments
Sign in, to comment.