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.

‍

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?"

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.

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.