What worries me most about software supply chain attacks right now is how little we know about what actually lands on our engineers' machines.
A developer used to pick a package, read the README and maybe check who maintains it. Today an AI coding agent decides it needs a library, picks one, installs it and runs it, often in seconds and often without anyone reading the name. Researchers have shown that models sometimes invent package names that do not exist, and anyone can register those names. Meanwhile malicious packages built to steal credentials appear on npm and PyPI every week, and the engineering box is exactly where the access to source code, cloud accounts and production lives.
So the question I keep coming back to is practical: how do we see, and control, what gets pulled onto those machines? Most answers begin with "install an agent on every developer laptop". That is a good end state, and a hard first step. It means a rollout, a pilot group, exceptions for build servers, and a few weeks before anything is protected.
This week I spent time with Socket, and what stayed with me was not a feature. It was the order you can do things in. You do not have to start on the endpoint.
Why this kind of threat intelligence is different
Most threat intelligence I use is about infrastructure: IP addresses, domains, file hashes, actors. It tells you who is attacking. It says very little about the npm package a developer installed this morning.
Socket's threat feed is built the other way round. It lists malicious open source packages by ecosystem, name and version: malware, typosquats, packages that steal credentials at install time. Socket says it finds many of them within seconds of publication, using AI scanning followed by human review. That is the intelligence you need for the attacks we keep seeing against developers, and there are not many feeds like it. JFrog runs one, and the open source community maintains a free one through OpenSSF. Most traditional threat intelligence and IoC vendors do not cover packages at this level.
Three steps, in the order I would take them
1. See what you already have, with nothing installed
Start with the feed. Take the list of known bad package versions and search for them in what you already run: your repositories, your build logs, your software composition and vulnerability tools, your code search. Socket's dashboard also shows whether a campaign's packages appear in your connected repositories.
This takes days, not months, and it answers the first question anyone asks when a new campaign is announced: are we already affected?
2. Control what comes in, at the network
Next, put a firewall in front of the package registries. Socket Firewall's registry mode runs as a service between your package managers and the public registries: npm, PyPI, Maven, Cargo, RubyGems, NuGet, Go, Conda, OpenVSX for editor extensions, and Hugging Face model downloads. Developers and build servers point at it instead of the public registry. A known malicious package gets blocked with a clear message, and everything else passes through.
Two things make this step more valuable than it sounds.
- It fits the network you already have. The firewall can sit behind your corporate egress proxy, so it works alongside a secure web gateway such as Zscaler. Nobody's laptop needs to change apart from a registry setting.
- It tells you what is actually used. Every download is logged, including the ones an AI agent decided on by itself, so for the first time you see which packages, in which versions, really enter the company. That is an SBOM built from reality instead of from what a manifest claims, and it is a hunting dataset: when the next campaign is announced, you search your own download log instead of asking every team.
3. Cover the machine itself
The last step is the developer's own machine, for the downloads that never touch your network or bypass the registry setting. Socket Firewall also runs locally as a wrapper around the package manager (sfw npm install). The free version needs no account and blocks confirmed malware for npm, yarn, pnpm, pip, uv and cargo, so any developer can start today. The enterprise version covers more ecosystems and reports to the dashboard.
Start this step with the people who hold the most access: platform, DevOps, anyone who can reach production, and anyone who lets an AI agent install packages on their behalf.
What it does not solve
A package firewall is one layer, not the whole answer. It does not stop a fake recruiter's take-home test that the developer runs by hand, a stolen session token, or a malicious editor extension installed from somewhere other than the registry you control. Those need application allowlisting, short-lived credentials and an approval step outside the systems that move money or data.
Other vendors in the software supply chain category, such as Sonatype Firewall and JFrog Curation, also block packages at the registry. Compare them on how fast new malware reaches the block list, which ecosystems they cover, and what the logs give you.
Why I like this
Good security tools usually make you choose between fast and thorough. This one lets you start where you are: a feed you can search this week, a proxy that fits the network you already run, and an agent when you are ready. Each step stands on its own, and each one makes the next easier.
If you know other threat feeds that track malicious packages at this level, I would like to hear about them.
Sources: Socket documentation on the threat feed, Socket Firewall, registry mode and the free wrapper.
