Today, we're launching our free & open-source malicious dependency firewall to defend against supply-chain attacks and malicious packages before they reach your machine. This protects from both transitive dependencies and attacks on established libraries, such as the one on LiteLLM last week.
Supply-chain attacks are more dangerous than ever
Security is all about covering your blind spots, and at Strix, we're acutely aware how hard that can be, especially in the age of AI.
Any time you (or your employees, or your agents) use or install a third-party library from the internet, you are (knowingly or not) trusting thousands or millions of lines of unread code from unknown sources with direct access to your machine, and any services, infrastructure, API keys, or confidential information it may have access to. If you use a third-party library in production, then you are also trusting it with your entire business.
Worse still, even trusted, established libraries aren't guaranteed to be free of malicious code, because these libraries are being constantly updated, and themselves can depend on hundreds or thousands of dependencies. This was made especially clear when LiteLLM was compromised just last week.
Supply-chain attacks allow attackers to compromise tens of thousands of repositories en masse by creating one small malicious dependency and spreading across an entire ecosystem, and they're far easier to execute than most developers assume.
A decade ago, the left-pad incident famously showed how far even obscure packages could reach, even unintentionally, when an 11-line package removed from npm took down Facebook, Netflix, PayPal, and Spotify (among others, of course).
Bad actors target maintainers of trusted libraries, injecting malicious code into them which can then spread naturally from package-to-package. They do so quietly and cover their tracks, and have shown again and again that no library is safe.
Last September, the Shai-Hulud worm spread across more than 1,200 packages with over 2 billion combined monthly downloads, collecting API keys & credentials, especially npm tokens of library maintainers, which it used to spread itself further. Over a year later, there are still constant news stories about newly compromised packages (for instance, this one, from earlier this month). Last November, 150,000 malicious packages were uploaded to npm.
AI agents, of course, only exacerbate this problem. They install and run code from unknown packages entirely without their users' knowledge. A totally innocuous prompt generating zero lines of code can silently compromise an entire machine.
Manually monitoring your code's dependencies or your agent's installs is not only infeasible, it's also not a defense. To really defend against supply-chain attacks, you need constant, automatic monitoring of all your package installations, with up-to-date security research.
Strix Firewall: Free, up-to-date, system-level monitoring
Existing open-source solutions get applied at the command-line. Something like:
| 1 | alias npm="cli-firewall-program npm" |
| 2 | |
| 3 | # Firewall wraps around npm for this particular install |
| 4 | npm install possibly-malicious-package |
This is not a bad first line of defense (and the Strix firewall does support something like this style of usage1 for users who prefer a less invasive firewall installation), but it is also a brittle one.
Usually this means your firewall needs to reimplement large portions of npm (and pip, and cargo, and gems, etc.) to parse CLI arguments and lockfiles correctly. This is no easy task, and indeed, the firewalls we looked at usually showed large coverage gaps. In several projects we examined, using real CLI arguments the firewall did not support, or even just updating a package manager silently disabled the firewall (in some cases, permanently, by overriding the alias).
It also doesn't scale well across an organization, or even across a single machine. Changes to your environment can silently disable your firewall, and agents can easily bypass them in a number of ways (including simply referring to package managers using their full path, as coding agents frequently do).
A better solution is an OS plugin which can intercept all traffic, from all sources, and block any installation of packages known to be malicious.
Even this is not enough, because new vulnerabilities are constantly being published & discovered. A firewall is only as good as its blocklist and safety depends on getting accurate advisory reports as quickly as possible. Strix taps into existing public resources for known malicious packages, such as OSV.dev & the OSSF's malicious-packages repo. We will also be running Strix on every new release from the most popular packages across every major registry, covering over 99% of installs, to check for any malicious changes and add them to the firewall's blocklist.
This is the service Strix provides: constant, silent, configurable OS-level monitoring of all package installations across your entire device, not just individual terminal sessions or via brittle aliases.
A one-time installation protects your device with up-to-the-minute security research. For free, forever.
Other products taking this approach are closed-source & paid. They install a trusted certificate on your machine and use it to intercept, decrypt, and scan all of its traffic.
At Strix, we like to bet on open-source. We believe a strong community will always outperform walled gardens, and that transparency is how you build trust with your users: anyone can read, contribute to, or modify our code, so that you can trust your defenses are strong and your privacy's intact.

Footnotes
-
Although only for package managers such as
npm&pipwhich supporthttp_proxy-style environment variables which allow redirecting traffic to a proxy server where we can host our firewall. This avoids the parsing/lockfile issues other firewalls have. ↩

