Strix Supply Chain Firewall: What It Blocks and the Defaults Worth Changing

Direct answer

On October 26, 2026 Strix announced its free, open-source "Supply Chain Firewall"; v0.1.2 was published the same day. Strix says it checks each package name and version against a malicious-package blocklist before it reaches your machine, and blocks a match. It runs two ways: machine-wide (an OS plugin Strix says intercepts package-install traffic) or command-prefix (firewall npm install left-pad). Strix also describes http_proxy-style usage for package managers that support it, such as npm and pip. It is a different product from the Strix AI pentest agent we reviewed at /blog/strix-ai-pentester-honest-review. We verified the release checksum and the --help output; we did not run installs through it, so we are not vouching for its blocking in practice. [S1, S2, S3]

What it is

Strix describes the firewall as defending against supply-chain attacks and malicious packages "before they reach your machine," covering both transitive dependencies and attacks on established libraries, and it names last week's LiteLLM compromise as the kind of attack it targets. The code is Rust, Apache-2.0 licensed, in the usestrix/firewall repo, with the blocklist in usestrix/firewall-blocklist. Screening runs on your device: downloads go straight to the registry, never through a Strix server. [S1, S2]

The blocklist is assembled from OSV.dev, the OSSF malicious-packages repo, other public reports, and Strix's own monitoring of top packages, and it updates without user action. Strix says it "will also be running Strix on every new release from the most popular packages across every major registry, covering over 99% of installs." That 99% figure is Strix's own claim, stated in the future tense, not something we measured. [S1, S2]

Two modes: machine-wide vs command-prefix

Machine-wide, according to Strix, installs an OS plugin that intercepts all package-install traffic from all sources and blocks known-malicious packages. That is a vendor coverage claim about package installs, not evidence that it intercepts all network traffic or every possible download path. Strix argues this is more robust than CLI aliases: an alias like alias npm='firewall npm' has to reimplement each package manager's argument and lockfile parsing, and in projects Strix examined, an unsupported CLI flag or a package-manager update silently disabled the alias (sometimes permanently, by overriding it), while an agent could bypass it by calling the package manager by full path. That last point is worth testing if you run AI coding agents that invoke tools directly. [S1, S2]

Command-prefix is the lighter install: you run firewall npm install <pkg> or alias your package manager to it. Separately, Strix describes http_proxy-style variables for package managers that support them, such as npm and pip. The checked help describes serve as serving a local registry for package managers configured to use it; the README lists port 8080 as the command-prefix default. Our evidence does not establish that serve is an HTTP proxy or provide the proxy-variable setup. As a general trial recommendation, start with the explicit prefix command. [S1, S2, S3]

What it covers

Registries and package managers (both modes): npm (npm, pnpm, bun), PyPI (pip, uv, pdm, pipenv), crates.io (cargo), the Go module proxy (go), and RubyGems (gem). Private mirrors like Artifactory and Nexus are configured in the config file. The --help output on the Linux build we checked lists the same managers plus pip3. [S2, S3]

Platforms differ by mode:

So in the README, Linux supports command-prefix mode; machine-wide is still Coming Soon. [S2]

The defaults worth knowing

Three defaults are worth reviewing before you rely on it:

• 24-hour hold on new versions (min_age_hours, default 24). New packages are blocked by default; Strix's reasoning is that malware is usually detected within a day of upload. Set it to 0 to turn the hold off, or use allow to exempt specific packages (known malware is still blocked for allowed packages). [S2]
• fail_open default true. The README defines this as allowing a package when it cannot be checked. That favors availability over blocking on an unsuccessful check; our evidence does not specify failure types or whether they produce alerts. If your threat model favors "block when unsure" over "never break a build," set fail_open: false and test failure behavior before relying on it. [S2]
• telemetry default true. Anonymized usage events are logged to Strix. If you would rather disable those usage events, set it to false. [S2]

An illustrative config fragment that disables usage telemetry and opts out of fail-open behavior looks like this (not tested here):

{
  "min_age_hours": 24,
  "fail_open": false,
  "telemetry": false
}

Config lives in an admin-only path for machine-wide installs (/Library/Application Support/Firewall/ on macOS, %ProgramData%\Strix Firewall\ on Windows) and a per-user path for prefix mode (~/.config/firewall/ on Linux, ~/Library/Application Support/com.usestrix.firewall/ on macOS, %APPDATA%\usestrix\firewall\config\ on Windows). [S2]

How it relates to recent incidents

The LiteLLM 1.107.0 compromise last week shipped credential-stealing malware through PyPI and public container registries from a hijacked release pipeline (our breakdown: /blog/litellm-1-107-0-supply-chain-what-to-check). [S4] For related reading, see our keyv npm worm article. Our LiteLLM article does not establish keyv incident mechanics, so that link is not evidence for this comparison. A blocklist firewall is one layer against that class of attack: it helps once a malicious package or version is known and listed, while the age hold is intended to leave time for detection. [S2; limits are general interpretation] As a general limitation, a malicious version that remains unlisted after the hold expires, or is exempt from the hold, may escape these checks. Do not treat install screening as recovery for an affected environment. Our evidence does not establish that this firewall listed or blocked the LiteLLM or keyv artifacts, or that it screens container images. Strix cites the Shai-Hulud worm last September spreading across "1,200+ packages with 2B+ combined monthly downloads," "150,000 malicious packages" uploaded to npm last November, and the 2016 left-pad incident as the backdrop for the tool. Those are Strix's figures, which we did not independently verify. [S1]

Strix also characterizes competing products as "closed-source & paid," saying they "install a trusted certificate on your machine and use it to intercept, decrypt, and scan all of its traffic." That is Strix's description of unnamed competitors, presented here as its claim, not our assessment. [S1]

Who should try it, who should wait

Worth trying now, as an editorial recommendation: developers and teams who run AI coding agents, and anyone who installs from npm, PyPI, crates.io, Go or RubyGems and wants local screening with downloads going directly to registries. Usage telemetry is on by default. [S1, S2] On Linux, start with command-prefix since machine-wide is not ready.

Wait, or proceed carefully: environments that cannot tolerate fail_open: true without first flipping it to false; anyone who treats telemetry-on-by-default as a non-starter until they have set it false; and anyone expecting this to replace build-time controls. At v0.1.2 with a young repo, treat it as a useful added layer, not your only one. As general defense-in-depth advice, keep hash-pinned lockfiles and digest-pinned images regardless; this is not a claim of firewall image coverage.

Try it safely: a 5-step checklist

These are trial recommendations, not a blocking test we performed. Verify a downloaded release asset before installing it.

1. Choose command-prefix mode on one machine (cargo install strix-firewall or the installer script), not machine-wide across your fleet.
2. Verify the download. Run sha256sum -c against the published .sha256 for the release asset before you install. We did this for the Linux x86-64 v0.1.2 tarball and it returned OK. [S3]
3. Set your config before real use: telemetry: false if you do not want to send events, and decide fail_open deliberately (true allows a package that cannot be checked; test the behavior with false).
4. Test on a non-critical project first. Install a few normal dependencies and confirm your workflow still works with the 24-hour hold in place; tune min_age_hours or use allow if the hold blocks a legitimate fresh release you need.
5. Only then consider machine-wide (macOS or Windows today) if you want the broader package-install coverage Strix describes, and review the admin-only config path so the settings above apply there too.

FAQ

Is this the same Strix as the AI pentest agent you reviewed?
No. This is the Strix Supply Chain Firewall (usestrix/firewall), a package-install blocker. The AI pentest agent is a separate product covered at /blog/strix-ai-pentester-honest-review. [S2, S4]

Does it send my code or packages to Strix?
Strix says screening runs on your device and downloads go straight to the registry, never through a Strix server. Separately, telemetry is on by default and logs anonymized usage events to Strix; set it to false to stop that. [S2]

Will it block a brand-new compromise?
It blocks what is on the blocklist, and holds new versions for 24 hours by default because malware is "usually detected within a day" (Strix's reasoning). The hold is intended to delay fresh versions, including unlisted ones. As a general limitation, an unlisted malicious version may still pass once the hold expires or if the package is exempt from the hold. Neither control is a complete defense. [S1, S2]

Does it work on Linux?
Command-prefix mode, yes (glibc 2.35+, x86-64/arm64). Machine-wide on Linux is listed as Coming Soon. macOS and Windows have both modes. [S2]

Did you test that it actually blocks malware?
No. We verified the v0.1.2 release checksum and read the --help output. We did not run any installs through it, so we make no claim about its blocking in practice. [S3]

Sources

Firewall facts come only from the vendor sources. LiteLLM incident claims are checked against our October 26 LiteLLM article; other internal links are related reading.

• S1: Ian Graham Martinez, Strix, October 26, 2026, Introducing Strix Supply Chain Firewall. Coverage, 99% claim, competitor characterization and Shai-Hulud/npm figures are Strix's own claims.
• S2: usestrix/firewall GitHub repo README and release metadata (v0.1.2, published October 26, 2026), fetched October 28, 2026. Modes, platforms, registries, config keys and defaults.
• S3: Protego check of the v0.1.2 Linux x86-64 release, October 28, 2026. sha256sum -c against the published checksum returned OK; firewall --help output read. No installs were run through it.
• S4: Related Protego content listed in our evidence: Strix AI Pentester: An Honest Review (different product), the October 26 LiteLLM article, and the Claude Code skills/MCP risks article. The keyv link above is related reading, not an incident source here.

Limitations

We verified only the v0.1.2 Linux release checksum and its --help output. We did not install the firewall machine-wide, did not run any package install through it, and did not confirm that it blocks any specific malicious package, so nothing here is a test of its effectiveness. The 99% coverage figure, the competitor description, and the Shai-Hulud/npm figures and left-pad reference are Strix's own claims as published in its announcement, not independently verified. Platform requirements, config defaults and the Linux "Coming Soon" status reflect the repo as of October 28, 2026 and may change in later releases.