GitHub package firewall preview: prove the npm path
GitHub’s October 20 preview adds a policy checkpoint for npm downloads. A useful pilot proves which requests reach it and how blocked fixes get reviewed.
Quick answer
GitHub announced its package firewall public preview on October 20, 2026 for GitHub Enterprise Cloud customers, initially supporting npm packages. Enterprises configure policy, then direct endpoints through the firewall. Pilot it with one repository and verify metadata requests, downloads, cache behavior and exception ownership. Treat its preview scope and actual request coverage as separate questions.
On this page
GitHub’s package firewall public preview adds an enterprise policy checkpoint to npm package requests. To evaluate it, configure a small canary and prove that its metadata requests and downloads take the intended route. A registry setting alone does not establish coverage across CI runners, developer machines, coding agents and existing caches. This analysis describes the October 20, 2026 announcement and documentation checked on October 21. [1][2]
What did GitHub announce on October 20?#
The announced preview is available to GitHub Enterprise Cloud customers, including enterprises with data residency, and currently supports npm packages. GitHub says the service is free during preview and will move to metered usage at general availability. No future price or general-availability date is established by that announcement. Confirm the current terms when making a purchase or rollout decision. [1]
The firewall evaluates requests against enterprise policy before packages reach configured endpoints. The announcement names cooldown, advisory checks and supply-chain controls. Setup documentation adds the operational details: endpoint configuration, permissions and exception management. Draw the actual path from the runner to the registry before changing every endpoint. [1][2]
Our worked case is an illustrative Enterprise Cloud team with an npm service, one CI runner and a coding-agent environment. It already has a committed lockfile and a private package scope. The team wants to know whether the preview can gate public npm downloads without breaking its private-package route or turning every urgent dependency fix into an unowned override. No enterprise tenant was exercised for this article.
Which requests will reach the policy checkpoint?#
Only requests routed through the firewall can be evaluated there. GitHub instructs enterprises to configure policy and then point endpoints at the enterprise-specific registry URL. The documentation’s npm setup uses user-level configuration and an enterprise-member user or bot token. Follow that current guidance in the canary; do not assume an automatically provided CI token has the same membership or access properties. [2]
npm takes configuration from command-line arguments, environment variables and several npmrc files. A project or scope setting can therefore matter alongside a user-level registry setting. Inventory the effective public registry and each relevant private scope in the actual job environment. Avoid printing authentication configuration or dumping the entire environment into a log. [3]
# Replace ENTERPRISE with the enterprise slug.
# Set GITHUB_TOKEN securely for the approved member/bot identity.
registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}
# Preserve a real private scope's intended route, if applicable.
# @your-scope:registry=https://private-registry.example.com/The private-registry line is a placeholder, not a GitHub-required setting. In our case, the platform owner records why that scope exists and which public dependencies it can expose indirectly. An agent running in another home directory or container can read a different configuration. Inspect its route separately instead of assuming it inherits the developer workstation’s npmrc. [3]
The official docs also describe an Artifactory integration and explicitly call that support experimental. If your endpoints use Artifactory, include its remotes and caches in the path inventory. The proposed design should identify whether an upstream public request passes through the firewall and which existing cache can satisfy an installation without making that request. Do not treat a proxy setting as a retroactive scan of everything already cached. [2]
What should the canary decision record contain?#
Give the canary an owner and write down which request should be allowed or blocked. For this hypothetical team, the initial decision is to pilot one nonproduction repository, keep the existing lockfile fixed and collect evidence before broad endpoint changes. The table below is our acceptance plan; its cells describe checks to perform, not successful observations from a test tenant.
| Path or event | Evidence to capture | Decision if evidence is missing |
|---|---|---|
| Cold public npm install | Metadata and tarball hosts plus matching policy observation | Do not claim download coverage |
| Warm install from runner cache | Whether any remote fetch occurred | Report cache behavior separately |
| Private package scope | Expected registry and dependency resolution | Repair the scope route before expansion |
| Coding-agent install | Effective configuration and request route in that environment | Keep that endpoint outside the coverage claim |
| Intended cooldown rejection | Exact version, rule and exception request link | Resolve the test setup before rollout |
| Urgent approved dependency | Named reviewer, narrow version and recorded reason | Hold deployment pending the documented decision |
A green install can come entirely from a warm cache. It may use a private registry or a different client configuration. An install that fails is also insufficient: distinguish authentication, DNS or registry reachability from the intended policy rejection. Preserve the error category and policy context so the review can tell whether the firewall was involved.
# Run inside the actual canary job environment.
npm --version
npm config get registry
# Use an isolated disposable copy of the canary repository.
# npm ci removes node_modules; do not run this in an active workspace.
canary_cache=$(mktemp -d)
npm ci --cache "$canary_cache" --ignore-scripts --no-audit --no-fund
# Repeat with that cache to distinguish remote and local behavior.
npm ci --cache "$canary_cache" --ignore-scripts --no-audit --no-fundThis first pass intentionally avoids install scripts so route diagnosis does not depend on executing package hooks. It does not prove that the application builds when those hooks are needed. Once the route is understood, run the repository’s approved installation and build procedure in its isolated environment, with the normal script policy, and verify the actual product behavior. [4]
npm ci uses the project lockfile and does not rewrite it. Preserve that property when comparing the two passes; do not replace the experiment with an unconstrained dependency update. Also record the lockfile’s resolved locations and the client version. The acceptance criterion is observed request coverage for the tested install, not a claim that every package spec or future lockfile will follow the same path. [4]
How should a blocked security fix be handled?#
Use a benign package/version selected for the intended policy condition in a nonproduction canary. There is no need to install malware to establish that a cooldown decision is being enforced. Record the configured rule and compare it with the version’s publication information. If the outcome differs, diagnose it before changing controls just to make the test pass.
A cooldown creates a real trade-off for urgent updates. Our proposed decision record asks the dependency owner to name the exact version, why it is needed, what review was performed and who may approve it. Keep that review distinct from an authentication repair. A successful token fix should not silently become permission to override a package policy.
GitHub’s documented exception flow can widen an allowance to all versions with a wildcard. For this pilot, our recommendation is to request only the reviewed version unless the owner can defend a broader scope. Assign someone to review and remove obsolete exceptions. This is an operating recommendation for the canary, not a claim that GitHub automatically expires each approval. [2]
What would justify expanding the pilot?#
Expand after the team can explain both a permitted path and an intended rejection, including the actual package-download route. Record the cold-cache result, warm-cache result, private-scope behavior, agent behavior and reviewer response. A missing row in that evidence record means the corresponding endpoint remains unverified; it should not disappear into a single “firewall enabled” status.
The dated announcement establishes npm support and Enterprise Cloud eligibility. It does not establish coverage for other ecosystems, promise that every malicious package is detected, or prove that your runners cannot bypass the route. The pilot should state residual paths and the separate network or endpoint controls you choose to enforce. Avoid converting a public preview into a blanket supply-chain guarantee. [1]
Package installation is one part of delivery security. The GitHub Actions hardening guide examines workflow permissions and untrusted inputs. The license-compliance rollout guide considers a different policy gate. Keep their review records separate: an allowed download does not establish safe workflow permissions or an acceptable license.
Questions about the package firewall preview#
- Is this generally available?
- No. The October 20, 2026 announcement and documentation observed on October 21 describe a public preview. Treat the article as a dated assessment of that preview. Before a later rollout, recheck eligibility, supported ecosystems, integration behavior and pricing rather than relying on a future promise. [1][2]
- Does the preview cover Python or Maven packages?
- The announcement says the current preview supports npm packages. Do not infer support for other ecosystems from the general term package firewall. Inventory the package managers your endpoints actually use and keep unsupported ecosystems outside the pilot’s protection claim. [1]
- Does a configured registry prove every installation was checked?
- No. Establish the route in the actual endpoint environment and distinguish cached content from remote requests. Scoped registries, different npmrc files and separate agent environments need their own observations. Report the endpoints and installation cases you verified rather than treating a single setting as universal coverage. [2][3]
- Can the pilot disable install scripts?
- The diagnostic command shown uses ignore-scripts to simplify the first route check. That changes installation behavior and may skip work the application needs. Complete a later build check under the repository’s approved script policy before judging the pilot suitable for delivery. [4]
- What is known about the future price?
- GitHub says the preview is free and general availability will use metered usage. The announcement does not provide a future unit price or a general-availability date. Keep a later cost check in the adoption decision instead of inventing an estimate from the preview’s current price. [1]
