GitHub Previews npm Firewall for Install-Time Package Controls
GitHub has introduced npm Firewall in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud. The service is designed to block suspicious npm packages at installation time by acting as a policy gate between endpoints or internal registries and upstream public package repositories.
The initial release supports npm packages only. GitHub says the firewall inspects both metadata requests and package downloads, allowing organisations to apply controls before a dependency reaches a developer machine, coding agent, CI runner or build host.
Policy checks at the dependency boundary
Administrators configure the rules that determine whether a requested package can be downloaded. One control blocks known malware by checking active malware advisories in the GitHub Advisory Database. Another evaluates vulnerabilities affecting the requested package version.
The vulnerability rule defaults to blocking only Critical severity issues. Enterprises can instead choose High or higher, Medium or higher, or any severity. This makes the decision part of an explicit installation policy rather than leaving every endpoint to retrieve packages directly from a public registry.
- Known-malware checks using active GitHub Advisory Database advisories.
- Vulnerability blocking by a chosen severity threshold.
- Attestation downgrade detection for requested versions.
- Detection of newly introduced preinstall and postinstall scripts.
- A minimum-age cooldown for recently published package versions.
Attestations, scripts and package age
The attestation control compares the requested package version with earlier releases and can stop a download if the requested version lacks an SLSA attestation. GitHub also examines whether a package has recently added scripts that run through preinstall or postinstall hooks, which can be abused to steal sensitive data.
Administrators can impose a cooldown period that prevents installation of versions newer than a specified minimum age. The setting ranges from one to 365 days, defaults to one day, and can be disabled by setting it to zero. A blocked package can be submitted for an exception, subject to approval by enterprise administrators and security managers.
Why automated installs raise the stakes
GitHub highlighted the exposure created when AI agents and CI runners install dependencies automatically to complete a task or build, without an explicit user decision for each package. Routing those requests through the firewall allows an organisation to apply the same policy controls before an automated workflow consumes a public dependency.
The approach follows wider adoption of waiting periods across open-source ecosystems. Rust 1.100, scheduled for release on November 12, 2026, is preparing a configurable global-min-publish-age option in cargo/config.toml; if it is not specified, Cargo will apply a seven-day window that skips newly published releases. npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm and Yarn have also implemented similar waiting periods.
Socket noted that a cooldown delays legitimate fixes as well as risky releases, and that malicious code can outlast the waiting period if it escapes detection. For businesses, npm Firewall provides a practical point to define how automated and manual dependency installs are screened, while retaining an approval process for justified exceptions.