In September 2025, attackers compromised the npm account behind chalk, debug, and 16 other packages with a combined 2.6 billion weekly downloads, pushing versions laced with a crypto-clipper that silently swapped wallet addresses in a user's browser. No malware signature fired. No proxy blocked a known-bad domain. The packages installed from the real registry.npmjs.org, ran during a routine npm install, and behaved exactly like the legitimate library they replaced. This is the pattern behind nearly every major supply chain incident since 2018 — event-stream, ua-parser-js, node-ipc, xz-utils, tj-actions/changed-files, and the Shai-Hulud worm. Security teams keep asking EDR and network proxies to catch this class of attack, and keep being surprised when they don't. The problem isn't a tuning gap — it's architecture. EDR and proxies were built to watch endpoints and network traffic, not to evaluate whether a piece of code your build pulled in five minutes ago deserves to run at all.
Why can't EDR detect malicious npm and PyPI packages before they run?
EDR can't stop most supply chain malware because it's designed to profile process behavior after execution starts, not to evaluate package contents before install — and install-time payloads are often finished executing before any behavioral baseline can flag them as anomalous. Take node-ipc in March 2022: a maintainer added "protestware" that checked the victim's geolocation and, if it matched Russia or Belarus, overwrote files on disk. The malicious code ran once, inside a postinstall script, during a normal npm install — the exact moment most EDR agents treat as routine developer tooling activity, not a process worth scrutinizing.
The deeper issue is where EDR simply isn't present. GitHub Actions runners, GitLab CI jobs, and most serverless build environments are ephemeral — spun up for a single job and destroyed minutes later. There's no persistent host to install an agent on, no baseline to build, and no time to establish one even if you tried. And when payloads are sophisticated, EDR fails even on hosts it does cover: the xz-utils backdoor (CVE-2024-3094) was built into the build system over more than two years by a trusted co-maintainer using the handle "Jia Tan," and it was found by accident on March 29, 2024, when a Microsoft engineer noticed SSH logins were 500 milliseconds slower than expected — not because any antivirus or EDR product detected it.
Why do proxy and network allowlists miss dependency confusion and typosquatting attacks?
Proxies and egress allowlists miss these attacks because the malicious traffic looks identical to legitimate traffic — it comes from the same trusted registry domain, registry.npmjs.org or pypi.org, that every proxy configuration is already set to allow. Dependency confusion, the technique Alex Birsan published in February 2021, exploited exactly this blind spot: by publishing public packages with the same names as internal-only packages used at Apple, Microsoft, PayPal, Netflix, Uber, Tesla, and dozens of other companies, he got build systems to pull his packages automatically, over connections that every one of those companies' proxies had already approved.
Typosquatting works the same way. In May 2022, malicious PyPI packages ctx and a hijacked version of phpass exfiltrated AWS credentials and environment variables to a remote domain encoded using Unicode homoglyphs designed to blend into ordinary pip install DNS traffic. A proxy inspecting domain reputation sees nothing unusual — it's a resolvable domain answering HTTPS requests, the same shape as thousands of legitimate calls a build makes every day. Network-layer tools are built to answer "is this destination allowed?" Supply chain attacks are engineered specifically so the answer is always yes.
What did xz-utils, tj-actions, and Shai-Hulud prove about existing tooling?
They proved that reactive, host- and network-layer defenses catch supply chain attacks only after the damage is already spreading — if they catch them at all. Three examples from the last 18 months make the pattern hard to ignore:
- xz-utils (March 2024): A backdoor planted over two-plus years of patient social engineering inside a core Linux compression library, targeting OpenSSH authentication on major distributions. Discovered by luck, not tooling.
- tj-actions/changed-files (March 2025): A compromised GitHub Action was modified to dump CI/CD secrets into public workflow run logs. GitHub's own advisory and independent researchers estimated the tainted tag was pulled into more than 23,000 repositories before the malicious commit was identified and the tag reverted.
- Shai-Hulud (September 2025): A self-propagating npm worm used stolen maintainer tokens to automatically publish trojanized versions of every package those maintainers controlled, then harvested credentials from infected machines to repeat the cycle. It compromised over 500 packages within days, including packages maintained by security vendors themselves.
In each case, the compromise happened at the source — a maintainer account, a CI token, a build script — not on an endpoint an EDR agent was watching or across a network path a proxy was inspecting. By the time any of these were contained, the exposure window had already closed on its own terms.
Why is the CI/CD pipeline the blind spot both EDR and proxies share?
CI/CD is the blind spot because pipelines are ephemeral by design and treated as trusted internal infrastructure, which exempts them from the scrutiny applied to developer laptops. A GitHub Actions runner typically lives for the duration of a single job — often under 10 minutes — then is torn down completely. That's not enough time to deploy an EDR agent, build a behavioral baseline, or meaningfully monitor the host; most organizations don't even try. At the same time, CI egress has to be permissive by necessity: a build needs to reach package registries, container registries, artifact stores, and cloud provider APIs, so proxy rules end up broad almost everywhere they're deployed at all.
The tj-actions incident is the clearest illustration: the compromise lived entirely inside the CI layer, exfiltrating secrets through workflow logs that most security teams don't monitor with the same rigor as endpoint telemetry or network flows. No laptop was touched. No proxy rule was violated. The attack simply happened in the one place neither control was built to watch.
Can threat-intel feeds like Aikido's Intel catch malicious packages before they spread?
Threat-intel feeds can only flag malware after someone else has already been hit, analyzed the sample, and published an indicator — which makes them reactive by design, not preventive. Tools like Aikido Security bundle a malicious-package feed, marketed as Aikido Intel, into a broader ASPM platform, cross-referencing new installs against a list of package names, versions, and hashes already confirmed malicious elsewhere. That's useful for catching repeat offenders and known typosquats, but it cannot, by construction, catch a first-seen payload.
Shai-Hulud demonstrated exactly why that gap matters: during its roughly 48-hour outbreak in September 2025, the worm published new trojanized package versions faster than any feed could realistically catalog them, with newly compromised packages surfacing hour by hour rather than in a single batch. Looking across major incidents, the lag between initial compromise and public disclosure has ranged from a matter of hours (chalk/debug) to more than two years (xz-utils). A feed-based control is only as fast as its slowest link — someone has to get hit first, report it, and wait for the update to propagate before your build is protected.
How Safeguard Helps
Safeguard is built on the premise that you can't defend a build pipeline by watching endpoints or filtering network traffic after the fact — you have to evaluate what a dependency actually does before it's allowed to run anywhere in your environment. Every package pulled into a Safeguard-protected pipeline is analyzed in an isolated sandbox: install scripts, file writes, network calls, obfuscation patterns, and process behavior are all inspected before the package ever reaches a developer's machine or a CI runner. That's a fundamentally different checkpoint than EDR (which watches the endpoint after code runs) or a proxy (which watches the network path after a request is already trusted).
Because Safeguard intercepts at the package-manager and CI layer rather than requiring an installed agent, it covers exactly the environments that leave EDR blind — ephemeral GitHub Actions and GitLab CI runners, serverless build jobs, and short-lived containers that live and die in minutes. And because it evaluates behavior rather than matching against a list of previously confirmed threats, it's positioned to flag first-seen malicious packages — the Shai-Hulud pattern, the node-ipc pattern, the chalk/debug pattern — instead of waiting for a feed update that arrives after the exposure window has already closed.
For security and compliance teams, that behavioral, pre-execution checkpoint also produces the audit trail SOC 2 and similar frameworks expect: a record of what was blocked, why, and when, tied to tenant-scoped policies rather than a single global allowlist. The goal isn't to replace EDR or network controls — it's to close the gap they were never built to cover, catching supply chain malware at the one point in the pipeline where it's still possible to stop it before it runs.