GitHub Launches npm Firewall to Block Malicious Packages Before Installation

GitHub has announced that it's introducing a new package firewall as a preview to block installation of suspicious npm packages during installation time.

"The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate," GitHub said.

The feature, which currently supports only npm packages, is available in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.

How the Firewall Works

According to the Microsoft subsidiary, the firewall is placed between endpoints or internal registries and the upstream package repositories so as to deter malware attacks that compromise systems when packages are installed.

This behavior can expose users to severe security risks, especially when artificial intelligence (AI) agents and CI runners automatically install dependencies to complete a task or build without their explicit permission.

The idea is that endpoints like coding agents and CI/CD hosts use the firewall for their requests instead of directly pointing to the public package registries. The firewall then checks package downloads against policy controls such as minimum package age and malware advisories, and blocks downloads that do not meet those policies.

Policy Controls

To use the firewall, administrators are required to configure policy controls, such as the ones listed below:

• Block known malware by checking against the GitHub Advisory Database for active malware advisories
• Block packages based on the severity of vulnerabilities by checking the GitHub Advisory Database for flaws that affect the requested package version. The control defaults to "Critical only" as the severity level that blocks an installation, although users can choose "High or higher," "Medium or higher," or "Any severity."
• Block attestation downgrades by comparing attestations for the requested package version with those of earlier versions and stop the download if the requested version does not have an SLSA attestation.
• Block newly-introduced install scripts by checking whether the package recently added scripts that run using preinstall or postinstall hooks, which can be abused to steal sensitive data.
• Block packages based on a cooldown period that prevents versions that are newer than the configured minimum age from being installed. The value can range from 1 to 365 days. The default value is 1 day. Users can disable it by setting it to 0.

Users who need access to a package that gets blocked erroneously by the firewall can submit an exception request, which can then be approved by enterprise administrators and security managers.

Supply Chain Security and Cooldown Periods

The development comes as Rust 1.100, which is scheduled for release on November 12, 2026, readies to add support for a configurable minimum publish age, allowing security scanners and maintainers time to flag and block malicious crate releases before they can be installed or used by users.

The value, defined via the global-min-publish-age option in cargo/config.toml, allows users to specify a minimum publication age in days or weeks. If left unspecified, a seven-day waiting period is applied by default to skip releases published within that window.

Over the past year, similar waiting periods have been implemented across open-source ecosystems, including npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm, and Yarn, as a way to bolster software supply chain security by reducing the chance that a newly published, unreviewed version is immediately pulled into a build.

Cooldown periods help add friction and slow down attacks in which a bad actor publishes a poisoned version of a popular package after seizing control of a maintainer account, thereby preventing rapid spread through manual or automated installations.

"The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception," Socket said. "Malicious code also doesn't magically become harmless with age. A release that escapes detection can simply outlast the cooldown. The value is in buying researchers, maintainers, and registries time to act before the next dependency update carries an attack further."