GitHub package firewall vs Chainsaw

Questions and answers

As of 2 November 2026 (GitHub public preview). Source: GitHub’s announcement.

GitHub package firewall and Chainsaw are both registry proxies which refuse a package before the install completes. GitHub package firewall covers npm for GitHub Enterprise Cloud customers and is free during the preview. Chainsaw covers 16 package ecosystems, runs as SaaS or inside your own network, and publishes the decision engine under Apache-2.0.

What is GitHub package firewall?

GitHub package firewall is a registry proxy for npm that GitHub put into public preview on 20 October 2026. The firewall is part of GitHub Enterprise Cloud. Developer machines, CI hosts or an internal registry fetch npm packages through the firewall. GitHub package firewall checks both the metadata requests and the downloads against the enterprise’s policy before passing them on. Five settings make up that policy: known malware, vulnerabilities above a minimum severity, attestation downgrades, new install scripts and a minimum package age. GitHub package firewall is free during the preview, and GitHub has said the service will be billed by usage at general availability.

What does GitHub package firewall check?

GitHub package firewall checks every npm metadata request and download against five settings in the enterprise’s policy, according to GitHub’s documentation as of 2 November 2026. Each setting has a default, so a new enterprise is protected before anyone edits the policy:

• Known malware from the GitHub Advisory Database. On by default.
• Vulnerabilities above a minimum severity. The default blocks critical only.
• Attestation downgrades: a package whose earlier versions had SLSA provenance and whose new version does not. On by default.
• New install scripts: a version adding a preinstall or postinstall script the previous version did not have. On by default.
• Minimum package age: versions younger than a set number of days are refused. The default is 1 day, configurable from 1 to 365, or 0 to turn the check off.

Developers point npm at GitHub package firewall with a registry line in .npmrc and a GitHub token from a member of the enterprise, and coding agents and CI hosts need the same setting. When a package is refused, the developer can ask for an exception through a web form.

Do GitHub package firewall and Chainsaw do the same job?

For npm, largely yes. Both sit between your installs and the public registry and refuse a package before the package lands. Both refuse very new versions by default: GitHub’s minimum age is one day, and Chainsaw holds new versions for 48 hours and refuses packages first published less than a day ago. Both look at install scripts and at known malware. The difference is scope. GitHub package firewall is an npm service inside GitHub Enterprise Cloud. Chainsaw is a registry proxy for 16 ecosystems, running as SaaS or inside your own network, with an open-source decision engine.

Where is GitHub package firewall stronger?

GitHub package firewall is the simpler choice for an npm-only team already on GitHub Enterprise Cloud, for four reasons:

• Already in GitHub Enterprise Cloud. No server to run, no new vendor to approve, and policy sits next to the rest of your GitHub settings.
• The GitHub Advisory Database. Malware and vulnerability data come from the same source as Dependabot.
• Attestation downgrades. Refusing a release which lost the SLSA provenance its predecessors had is a simple signal against a hijacked publish.
• Price during preview. GitHub package firewall is free in public preview. GitHub has said it will be billed by usage at general availability.

If your organisation is on GitHub Enterprise Cloud and installs only npm, start with GitHub package firewall.

Where is Chainsaw different?

Which ecosystems are covered?

Chainsaw is a registry proxy for 16 package ecosystems, while GitHub package firewall covers npm only during the public preview that began on 20 October 2026.

GitHub package firewall: npm only during the preview.

Chainsaw: 16 package ecosystems through one proxy, including npm, PyPI, Maven, Cargo, Go, RubyGems, NuGet and Docker images. A team with Python services and Java builds routes pip and Maven through the same Chainsaw policy as npm.

Where can it run?

GitHub package firewall is a GitHub-hosted service, while Chainsaw runs as SaaS or inside your own network from one binary.

GitHub package firewall: a service hosted by GitHub for GitHub Enterprise Cloud customers. GitHub’s documentation does not mention GitHub Enterprise Server.

Chainsaw: SaaS, your VPC, self-hosted or fully air-gapped, all from the same binary, with no GitHub account needed. The VPC, self-hosted and air-gapped options are paid; the free Chainsaw CLI runs locally with no account. A team outside GitHub Enterprise Cloud, or one with no internet route from its build network, can still put Chainsaw on the install path.

Can you read the code that refuses a package?

Only Chainsaw lets you read the code behind a refusal, because the Chainsaw decision engine is open source under Apache-2.0 and GitHub package firewall is a hosted service with no public code.

GitHub package firewall: no; GitHub package firewall is a hosted service.

Chainsaw: the CLI and the decision engine are open source under Apache-2.0, published by Chain305 at github.com/chain305/chainsaw-core. A security team can read the function which returns the refusal before routing any installs through Chainsaw, and can run the same engine locally as a CLI with no account. The hosted product, with the dashboard, policy, SSO/SCIM and audit, is not open source.

What does it look at beyond advisories?

The difference is the signal count: Chainsaw evaluates 25 supply-chain signals beyond CVE data, and GitHub package firewall runs five checks.

GitHub package firewall: the five checks above: known malware, vulnerabilities, attestation downgrades, new install scripts and minimum package age.

Chainsaw: 25 supply-chain signals beyond CVE (up to all 25 on npm and PyPI, 22 on RubyGems, at least 4 on every proxied ecosystem), such as publisher changes, typosquat matching and what an install script would fetch or execute. Five seeded rules refuse from day one: CISA KEV, packages under 1 day old, install scripts fetching remote URLs, import-time execution and bidi Unicode. Every other rule runs in monitor mode first, showing what the rule would refuse, before refusing anything.

What about installs that skip the firewall?

The gap is the same for both products: a proxy firewall sees only the installs routed through the proxy. Laptops, CI hosts and coding agents all need the firewall’s registry setting, according to GitHub’s documentation, and Chainsaw has the same requirement. On a laptop, a single .npmrc registry line decides whether npm goes through either one. Chainsaw ships three ways to check the routing holds: first, a CI gate which fails builds pulled from elsewhere; second, MDM settings which pin laptops to the proxy URL; third, egress rules which block direct registry traffic.

When is GitHub’s firewall enough?

GitHub package firewall is enough when three things are true. First, the organisation is on GitHub Enterprise Cloud. Second, the installs that matter are npm. Third, the team would rather not run or buy anything else. The defaults already refuse known malware from the GitHub Advisory Database, versions younger than 1 day and newly added install scripts, and the policy sits next to the rest of the GitHub settings. A team which later adds PyPI, Maven or Docker, or needs a firewall inside its own network, can add Chainsaw for the other ecosystems and keep GitHub package firewall on npm.

When should you use both, or Chainsaw alone?

Use both when npm is one of several ecosystems: GitHub package firewall for npm, Chainsaw for PyPI, Maven, Go, Docker and the rest. Start Chainsaw in monitor mode first to see what Chainsaw would add without refusing anything.

Use Chainsaw alone when the firewall must run inside your own network or air-gapped, you are not on GitHub Enterprise Cloud, or your security team wants to read the code that makes the decision. The free Chainsaw CLI runs locally with no account.

For the wider category, from SCA scanners to artifact managers, see where Chainsaw fits.

Sources

GitHub package firewall is a public-preview product, so every GitHub fact on this page comes from GitHub’s own changelog and documentation, as checked on 2 November 2026.

• GitHub Changelog, GitHub package firewall in public preview, 20 October 2026.
• GitHub Docs, Protecting endpoints with package firewall.