Aikido

Why EDR and proxy won’t save you from supply chain malware

Written by
Samuel Vandamme

Most security teams check the EDR box, check the proxy box, and move on. Against supply chain malware, neither provides meaningful protection because they were built for a different problem. 

Traditional malware has a way of sneaking onto a machine, whereas supply chain malware gets invited. The developer runs npm install, and the malicious code lands with full permission to execute. That inversion breaks both tools at the design level.

A two-panel meme from The Office. In the top panel, Dwight stands smiling in an arcade, labeled "NPM INSTALL AXIOS." In the bottom panel, someone grabs him from behind, labeled "FREE MALWARE," as Dwight reacts in shock with the caption "F**k."

Why EDR misses malware

EDR watches processes for suspicious behavior: unusual syscalls, unexpected parent-child relationships, known malicious signatures. It asks, "Is this process acting like malware?"

A two-panel webcomic. In the top panel, a small security guard labeled "EDR" shines a flashlight into a dark room full of large menacing figures, all labeled "Malware." In the bottom panel, the malware figures have gotten behind the guard, but the flashlight is pointed at a small innocent figure labeled "RANDOM ZIP FILE."

The problem is that supply chain malware runs inside trusted runtimes, doing things those runtimes do all day. A postinstall script that reads `.env` files and POSTs the contents to an attacker looks identical to a build tool fetching credentials to deploy code. Both are node or python reading files and making HTTP calls. The syscalls and the network calls are the same. EDR has no context that one is legitimate and the other isn't.

In March 2026, attackers hijacked the npm account of the lead axios maintainer, a package with ~100M weekly downloads. They didn't touch the source. They added one new dependency whose only job was a postinstall script that pulled down a cross-platform RAT and deleted itself. To a process monitor, this was indistinguishable from npm install doing its job. It resolves a dependency, runs a hook, and makes an HTTP request.

Two months later, three versions of durabletask, a Python package in Microsoft's Azure ecosystem, were backdoored. The injection was about ten lines in __init__.py. The code fetches a file and runs it in a subprocess, swallowing exceptions. The second stage harvested credentials from AWS, Azure, GCP, Kubernetes, and Vault, then spread to other instances over SSM and to other pods via kubectl exec, using the victim's own credentials, hitting the victim's own cloud APIs. On hosts with Israeli or Iranian locale settings, a one-in-six roll ran rm -rf /*. No foreign binary, no anomalous destination. EDR has no model for the case where the package itself is the threat.

Supply chain attacks at this layer are so dangerous because the malicious payload is normal behavior. There’s no anomaly to detect, because the whole point is to blend into the noise, or in this case, to be the noise. 

Why proxies miss it

A proxy in the traffic path can intercept package downloads and check them against known-malicious packages. That works, in theory. The problem is the "in the traffic path" part.

A photo of a small yellow metal gate standing on a sidewalk with wide open grass on both sides, labeled "PROXY." The gate blocks the path but anyone could simply walk around it.

Remote and corporate proxies are opt-in controls on machines developers own. Developers work from home, from coffee shops, from hotel wi-fi. They install tools that bypass system proxy settings. VS Code manages its own extension downloads. npm, pip, and cargo have their own HTTP clients. Many CLI tools and language runtimes ignore HTTP_PROXY entirely unless explicitly configured. And when a tool breaks because of the proxy, developers disable the proxy, fix the tool, and forget to re-enable it.

Cases like these happen every day. A developer installs a compromised VS Code extension at 11pm from their personal machine. A CI runner pulls a poisoned dependency outside the corporate network perimeter. Neither of those installs go through the proxy. The scan never runs. The check that was supposed to catch it simply wasn't there.

What actually works

Both EDR and proxies solve real problems for the threats they were designed for and are still valuable. They just don't cover the developer-specific supply chain attack surface.

That surface needs something that lives on the machine itself, understands what packages are doing at install time, and is always present regardless of network configuration. We built Aikido Device Protection to do exactly that. Find out how a number of organizations are using Device Protection to protect developer machines in this blog.

If you want the fuller picture of what traditional endpoint tooling misses on developer machines, the MDM version of this problem is covered in this piece.

Share:

https://www.aikido.dev/blog/edr-proxy-wont-protect-supply-chain-malware

Subscribe for news

4.7/5
Tired of false positives?

Try Aikido like 100k others.
Start Now
Get a personalized walkthrough

Trusted by 100k+ teams

Book Now
Scan your app for IDORs and real attack paths

Trusted by 100k+ teams

Start Scanning
See how AI pentests your app

Trusted by 100k+ teams

Start Testing

Get secure now

Secure your code, cloud, and runtime in one central system.
Find and fix vulnerabilities fast automatically.

No credit card required | Scan results in 32secs.