npm firewall brings policy checks to package installation
The npm firewall now available in public preview can inspect software packages before they are installed and stop downloads that violate an organisation’s security rules. npm is an ecosystem used to distribute reusable software components, also called packages or dependencies. GitHub says the feature currently works only with npm and is available to all GitHub Enterprise Cloud customers, including customers using the data-resident version of the service.
GitHub, a Microsoft subsidiary, places the control between an organisation’s endpoints or internal registries and upstream package repositories. An endpoint can be a developer workstation, a coding agent or a continuous integration and continuous delivery host, commonly shortened to CI/CD, that automatically builds and deploys software. Instead of contacting a public package registry directly, these systems send package metadata requests and downloads through the new inspection layer. The npm firewall then applies the policies selected by enterprise administrators and refuses downloads that fail those checks.
This install-time approach is intended to address the point at which a harmful dependency can begin running on a system. The risk is particularly significant when artificial intelligence agents and CI runners automatically fetch dependencies while completing a task or preparing a build, potentially without a person approving each installation. Because package installation can execute software inside a development or build environment, a malicious release can expose systems and sensitive information before a later review identifies the problem.
One available policy checks requested versions against active malware advisories in the GitHub Advisory Database. Another can block versions affected by reported vulnerabilities. Its default threshold prevents installation only for vulnerabilities rated Critical, but administrators can instead choose High or higher, Medium or higher, or Any severity. These settings allow organisations to decide how restrictive the installation process should be, although GitHub requires administrators to configure the controls they want to apply.
The npm firewall can also look for changes in software provenance. It compares attestations attached to a requested package version with those associated with earlier releases and can stop a version that lacks an SLSA attestation, a record about how software was produced. This is designed to prevent an attestation downgrade, where a newer release no longer carries the provenance information available for previous versions.
A separate control detects newly added install scripts. These are commands that a package can run automatically through preinstall or postinstall hooks before or after installation. GitHub says such hooks can be abused to steal sensitive data, so the policy can block a package that has recently introduced them. This focuses attention on a meaningful behavioural change rather than treating every package script in the same way.
Administrators can additionally impose a cooldown period based on package age. Versions newer than the selected minimum age are prevented from being installed. The setting accepts values from 1 to 365 days, uses 1 day by default and can be disabled by setting it to 0. If a legitimate package is blocked incorrectly or is urgently needed, a user can submit an exception request for approval by an enterprise administrator or security manager.
The release-age idea is also reaching Rust, a programming language with packages known as crates. Rust 1.100, scheduled for release on November 12, 2026, is set to support a configurable minimum publication age. Users will be able to define a waiting period in days or weeks through the global-min-publish-age option in cargo/config.toml, a configuration file used by Cargo. If no value is specified, the planned default is a seven-day waiting period that skips releases published during that window.
Over the past year, similar waiting periods have been introduced across npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm and Yarn. Their purpose is to reduce the chance that a newly published and unreviewed version is immediately pulled into an automated build. They can also slow an attack in which someone takes control of a maintainer account and publishes a poisoned version of a popular dependency, giving researchers, maintainers and registries more time to identify and block it.
A waiting period is not proof that an older package is safe. Socket notes that legitimate fixes may also be delayed unless developers approve an exception, while malicious code that remains undetected can simply outlast the cooldown. For website owners and businesses, the practical lesson is to treat minimum package age as one layer alongside malware advisories, vulnerability policies, provenance checks and scrutiny of new install scripts, rather than as a standalone guarantee.
Organisations seeking support for the wider security of their build and hosting environment can consider AEU-I for security-first IT, infrastructure and consulting. Whatever support model is used, exception requests should receive a deliberate review because approving one removes the specific policy barrier that stopped the package.