What is a package firewall?

Questions and answers

What is a package firewall?

A package firewall is a registry proxy between a package manager (npm, pip, Maven, Cargo and others) and the public registry, which decides on every install whether the package may be downloaded. If the package fails policy, the install is refused and the bytes never reach the developer’s laptop or the build. Developers, coding agents and CI jobs reach the firewall through one registry URL in .npmrc, pip.conf or settings.xml. Policy can cover known vulnerabilities, licences, version rules, provenance and behavioural signals such as install scripts that fetch remote code. A refused package gets an HTTP 403 naming the reason, and the decision is written to an audit log. Chainsaw ships five seeded rules that refuse from day one, among them CISA KEV vulnerabilities, packages under 1 day old and install scripts fetching remote URLs, across 16 ecosystems.

How is a package firewall different from a vulnerability scanner (SCA)?

The difference between a package firewall and a vulnerability scanner (SCA) is the timing of the check. An SCA tool reads the dependencies already installed and reports on the installed set. A package firewall acts on the install request itself and refuses a bad package before download.

Timing matters most for malicious packages: an install script that steals environment variables runs the moment the package lands, before any scanner reads the package. An SCA finding arrives after the install, so a credential stealer has already run by the time the report lists the package. A package firewall can refuse the same package on behaviour, such as an install script fetching a remote URL, or by name once the package is on a known-malicious feed. Most teams run both: SCA for inventory and CVE reporting, the firewall for the refusal. The full SCA comparison is here.

How does a package firewall work?

1. You point each package manager at the firewall instead of the public registry: one registry URL in .npmrc, pip.conf, settings.xml and so on.
2. On every request, the firewall fetches the package from upstream and evaluates policy: known vulnerabilities, licence, version rules, provenance and behavioural signals.
3. An allowed package is served and cached. A refused package gets an HTTP 403 that names the reason, and the decision is written to an audit log.

What does a package firewall catch that a CVE feed does not?

A package firewall catches attacks that have no CVE yet when the attacks happen: install-script exfiltration, maintainer-account takeover, typosquats and dependency confusion, hidden Unicode in source, and worm-style publish bursts such as Shai-Hulud, flagged by CISA in September 2025. A CVE feed is a list of filed advisories, so a CVE feed only knows about a package once someone has filed an advisory.

Chainsaw evaluates 25 supply-chain signals beyond CVE (up to all 25 on npm and PyPI, 22 on RubyGems, at least 4 on every proxied ecosystem). For example, Chainsaw refuses import-time execution and bidi Unicode in source from day one, with no advisory needed. The full list is on the policy page.

How often does a package firewall block real malware?

Measured on one 1,098-package corpus, using only the packages’ own bytes and without the 231k-entry known-malicious feed:

• 43.7% of real malware hard-blocked (104 of 238 samples).
• 0.47% of top packages false-blocked (4 of 860).

So more than half of that malware was not refused on behaviour alone. The known-malicious feed sits underneath and refuses published malware by name. The corpus builder and harness are in the repository, and the four false blocks are named on the comparison page. Ask any vendor for the same two numbers on a corpus you choose.

Can developers route around a package firewall?

Yes, at the proxy itself. One line in .npmrc or pip.conf points a package manager straight at the public registry, and that is true of every proxy-based firewall, Chainsaw included.

The answer is enforcement in three other places:

• CI: a workflow gate fails the build when a package came from somewhere other than the firewall.
• Laptops: MDM settings (Jamf, Intune) pin package managers to the firewall URL, so the edit does not stick.
• Network: egress rules block direct registry traffic and force it back through the firewall.

Chainsaw ships all three and attests whether the gap is closed. It is defence in depth with detection, not a guarantee that nothing can ever get round it.

Is a package firewall the same as a cooldown or lockfile pinning?

No. A package firewall, a cooldown and lockfile pinning are separate controls, and the three stack. A lockfile such as package-lock.json or Cargo.lock keeps builds reproducible by pinning exact versions. A cooldown delays new versions by a day or a week, so smash-and-grab compromises are usually yanked before you pull the bad version. Chainsaw’s default 48-hour release hold hides too-new versions on npm, PyPI and Composer and refuses an exact pin on 17 other formats. Neither a lockfile nor a cooldown judges what a package does, and a worm that spreads through maintainers you already trust passes both. A package firewall evaluates each package on install and refuses an install script that fetches a remote URL even in a version older than the cooldown. How pinning, cooldowns, blocklists and SCA fit together.

Which package firewalls are there?

Several products refuse packages at install time:

• Socket, with behavioural analysis that is especially deep on npm.
• JFrog Curation, a policy gate in front of Artifactory.
• Sonatype Repository Firewall, in front of Nexus Repository, or self-hosted Artifactory through a plugin.
• CLI wrappers such as Aikido Safe Chain and Datadog’s Supply-Chain Firewall, which wrap one developer’s package manager rather than sitting in front of an organisation.
• Chainsaw.

They differ in where they run, which ecosystems they cover, whether you can read the code that makes the decision, and whether they close the routes around the proxy. Socket vs Chainsaw · Chainsaw vs JFrog Xray · Chainsaw vs artifact managers

Where does Chainsaw fit?

Chainsaw is an install-path firewall for 16 package ecosystems. The CLI and the decision engine are open source under Apache-2.0 at github.com/chain305/chainsaw-core; the multi-tenant server is the paid product. It runs as SaaS, in your VPC, self-hosted or air-gapped from the same binary, and every rule can run in monitor mode, showing what it would refuse, before it refuses anything.