GitHub Puts a Package Firewall in Public Preview for Enterprise Cloud, Screening npm Installs With a Default One-Day Cooldown
GitHub's package firewall, in public preview for Enterprise Cloud, checks npm downloads against malware advisories, attestation changes and a minimum package age; only npm is supported.
Overview
GitHub has introduced a package firewall that sits between build and developer endpoints and upstream package registries. According to the GitHub changelog, it “is available today in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.” The changelog entry is dated October 20, 2026.
GitHub frames the feature as a response to install-time malware. In the changelog’s words, “An increasing number of malware attacks exploit systems at package installation time, harvesting credentials on CI/CD hosts or developer workstations without even running the package’s code.” The firewall, GitHub says, sits between “endpoints like Actions runners or coding agents and the upstream package repositories, inspecting both metadata requests and package downloads for signs of malicious activity.”
What We Know
Administrators set policy for the enterprise, and endpoints must then be pointed at the firewall instead of directly at the public registry. The GitHub documentation lists five policy controls and their defaults:
- Block known malware: checks the GitHub Advisory Database for active malware advisories; defaults to On.
- Block vulnerability advisories: the administrator picks a minimum severity from Critical only, High or higher, Medium or higher, or Any severity; defaults to Critical only.
- Block attestation downgrades: blocks a download if earlier versions of a package had SLSA attestations but the requested version does not; defaults to On.
- Block newly-introduced install scripts: flags packages that recently added scripts such as preinstall or postinstall; defaults to On.
- Minimum package age: a cooldown for newly published versions, set between 1 and 365 days, or 0 to disable it; the default is 1 day.
The documentation says the registry URL is specific to each enterprise and that each request must carry an authentication token tied to a user or bot account that is a member of the enterprise. For npm, the documented setup is a user-level .npmrc entry pointing registry at a package-firewall.githubapp.com address. The documentation also describes a route through JFrog Artifactory, noting that “Artifactory support is experimental.”
When a package is blocked, the documentation says the npm output or CI/CD log includes a URL for requesting an exception. Enterprise administrators and security managers can review the request, and can optionally widen it from one version to all versions of a package.
The changelog states that “The service is free while in the preview period. When it reaches general availability, it will be charged based on metered usage, similar to Actions billing.”
What We Don’t Know
- Ecosystems beyond npm. The changelog says “Currently the package firewall only supports npm packages.” Neither source gives a timeline for other ecosystems.
- Pricing and availability. The sources give no per-unit rate for the metered billing and no general-availability date.
- Effectiveness. Neither source reports detection rates or how many packages the firewall has blocked during the preview.
Context
The release follows other npm supply-chain changes The Machine Herald has covered, including changes to npm trusted publishing configurations. Those concern how packages are published; the package firewall instead governs which published versions an enterprise’s own endpoints may install.
The one-day default cooldown and the Critical-only vulnerability default apply only if administrators leave the documented defaults unchanged. The documentation allows cooldowns of up to 365 days and a vulnerability threshold of Any severity.