What the package firewall does
The firewall sits between endpoints, such as Actions runners or coding agents, and the upstream package repositories. It inspects both metadata requests and package downloads. The idea is to enforce policy in the dependency-fetch path, before a bad version reaches a machine that holds secrets.
GitHub's documentation describes the intended uses: protecting dependency installs in CI builds, AI agent sessions and local development. That includes the AI coding agents that now pull in dependencies on their own, often without a human reading the install log.
Availability and cost
- Who gets it: All GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.
- Price today: The service is free during the preview period.
- Price later: GitHub's announcement says general availability will bring metered billing similar to Actions billing. It gives no rates and no GA date.
- Ecosystems: The firewall currently supports only npm packages. Python, Java, Go and other ecosystems are not covered yet.
- Status: GitHub's docs say the feature is in public preview and subject to change.
The policy controls
According to GitHub Docs, enterprise administrators and enterprise security managers configure the controls under the enterprise's Policies area, in the Package firewall section. The controls apply to every request that passes through the firewall.
| Control | What it does | Default |
|---|---|---|
| Block known malware | Checks the GitHub Advisory Database for active malware advisories | On |
| Block vulnerability advisories | Blocks by severity threshold: Critical only, High or higher, Medium or higher, or Any | Critical only |
| Block attestation downgrades | Blocks a version that lacks SLSA attestations when earlier versions had them | On |
| Block newly introduced install scripts | Flags packages that recently added scripts such as preinstall or postinstall | On |
| Minimum package age | Cooldown for new versions, from 1 to 365 days (0 disables it) | 1 day |
The cooldown is probably the most practical control. Many malicious releases are caught within hours or days of publication. A short delay costs little and gives the security community time to react.
The attestation check is also useful. If a package used to ship with SLSA attestations and a new version doesn't, that can point to a compromised publishing pipeline. Install-script detection is similarly well aimed, because install hooks are a classic route for credential theft.
Setup: policy alone isn't enough
Turning on policies in the enterprise console protects nothing by itself. Each endpoint has to be pointed at the firewall. The launch post is explicit that endpoints must use the firewall instead of pointing directly at the upstream package registries.
Configuring npm
Per the docs, you edit the user-level .npmrc. You set the registry to an enterprise-specific firewall URL and add an auth token for that same URL. Replace ENTERPRISE with your enterprise slug.
- Registry URL: the docs give the form
[url]https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE[/url]. The research notes quoted a slightly different host,github.com. GitHub Docs is the more detailed source and usesgithubapp.com, so copy the URL from the docs page and don't type it from memory. - Token: requests need a token tied to a user or bot account that belongs to the enterprise. It needs no more than read-only access to public repositories.
- Storage: keep the token in an environment variable such as
GITHUB_TOKENor a CI secret. Never commit it. - Alternative: you can apply the same settings with
npm config setcommands.
Using Artifactory
JFrog Artifactory support is labeled experimental. You need Artifactory administrator rights. In outline:
- Create a remote npm repository that points at your enterprise firewall URL.
- Authenticate it with a personal access token.
- Add it to a virtual npm repository alongside your private npm repositories.
- Exclude any remote that fetches straight from the public npm registry, so nothing can bypass the firewall.
That last step is the one most likely to be missed. A virtual repository that still includes a direct npmjs remote undermines the whole setup.
Handling false positives
Blocks will happen, and some will be wrong. GitHub's example is a new release that carries a security fix but is held back by the age cooldown.
- The npm output or CI log includes a URL for requesting an exception.
- The request form covers the repository, ecosystem, package name, version, a reason and an optional comment.
- Enterprise administrators and security managers review requests. They can approve the requested version or enter
*to allow all versions. The docs note that this broadens the exception. - Approved exceptions become part of the firewall policy. Administrators can review and remove them later.
- You can delegate policy management without full admin rights. Add the "Edit enterprise-level package firewall policy" fine-grained permission to a custom role.
Be careful with the wildcard. It is convenient for packages your enterprise owns, but it also gives up the per-version scrutiny that makes the tool worth having.
Practical advice for admins
This is analysis from general industry practice and the documented controls. It is not GitHub guidance.
- Inventory first. Find where npm traffic comes from: laptops, build agents, containers and AI coding tools.
- Check for bypasses. One stray
.npmrcor a direct-to-registry mirror leaves a gap. - Tune the cooldown to your release cadence. One day is the default. If you need urgent patches, plan for fast exception handling.
- Pilot on CI first. Build servers are often the most credential-rich targets and the easiest to configure centrally.
- Keep your expectations realistic. This reduces risk but doesn't eliminate it. A malicious package that isn't yet in an advisory and passes the age, script and attestation checks could still get through.
The bigger picture
The firewall fits a wider trend. Cooldown periods, provenance checks and registry proxies are becoming standard defenses as supply-chain attacks target install-time behavior. Self-hosted open-source proxies already exist, including projects that filter npm by age, advisories or lifecycle scripts. GitHub's pitch is a managed, enterprise-integrated version tied to its own Advisory Database and exception workflow.
The tradeoffs are clear. It is npm-only for now, limited to Enterprise Cloud, and its eventual metered pricing is unknown. For Enterprise Cloud shops with heavy JavaScript pipelines, the free preview is a low-cost chance to test it before billing starts.