Why EDR and proxies fail against supply chain malware

At a glance

What this is: Aikido argues that supply chain malware is harder to stop than traditional malware because it arrives through trusted developer workflows, making EDR and proxies unreliable as primary controls.

Why it matters: IAM and security teams should treat developer machines, package managers, and CI runners as execution boundaries, not just network endpoints, because install-time trust can defeat controls that only observe post-execution behaviour.

Context

Supply chain malware is malicious code delivered through software dependencies, package managers, extensions, or build workflows that users already trust. Traditional endpoint and network controls struggle here because the payload often executes as part of expected installation behaviour, not as an obvious intrusion. That creates a governance gap for developer estates, where identity, privilege, and execution trust intersect.

For IAM and NHI practitioners, the relevant issue is not only the malware itself but the machine identities and credentials available to the tools that install and build software. When a trusted runner or developer session can access cloud keys, tokens, and other secrets during installation, detection that depends on anomalous behaviour or network interception can miss the abuse entirely.

Key questions

Q: What breaks when supply chain malware can use trusted platforms as command channels?

A: Traditional network filtering and signature scanning lose much of their value because the malicious traffic looks like normal developer activity. Teams need lineage-aware detection, repository event monitoring, and identity-based controls around commits, tokens, and package publishing. Without those, the attacker can keep updating payloads inside a trusted environment.

Q: Why do developer package compromises create both malware and identity risk?

A: Because the compromised package often reaches credentials, tokens, and API access that the developer or CI runner already possesses. The attacker is not only executing code, but also abusing an existing trust relationship with cloud services and internal tooling. Once secrets are available locally, the compromise becomes an access problem as much as a code integrity problem.

Q: What signs suggest proxy-based supply chain controls are failing?

A: A key signal is when downloads, extensions, or dependency installs still succeed from unmanaged locations or through tools that ignore system proxy settings. Another is when developers disable the proxy to keep work moving and never restore it. If package acquisition is not consistently traversing the expected inspection point, the control is functionally absent.

Q: Should teams prioritise endpoint controls or network controls for supply chain malware?

A: Endpoint controls should take priority when the threat is local execution of trusted software, because the malicious action happens after the download and often outside the proxy path. Network controls still matter for blocking known-bad sources, but they cannot be the only checkpoint. The deciding factor is whether the control can observe install-time behaviour on the machine itself.

Technical breakdown

Why trusted install flows defeat endpoint detection

EDR is built to identify suspicious process behaviour after code is already running. Supply chain malware often hides inside legitimate installers, package hooks, or runtime actions such as file reads and HTTP calls, so the process profile looks normal. If a malicious postinstall script reads environment files, downloads a payload, and spawns a subprocess, those actions can resemble ordinary build tooling. That makes the difference one of context, not just behaviour. The detection problem is structural: the malicious code inherits trust from the execution path that launched it.

Practical implication: move control earlier in the execution path, before trusted install routines can inherit broad runtime permissions.

Why proxies miss developer-side dependency compromise

Proxy controls only help when traffic passes through them. Developer machines, CLI tools, package managers, and extensions frequently bypass corporate proxy settings, especially when users work off-network or tools ignore system configuration. In that model, the control is optional while the threat path is mandatory. A poisoned dependency fetched by npm, pip, or a code editor extension can land outside the proxy’s visibility and still execute locally. That means network inspection is an incomplete trust boundary for software supply chains.

Practical implication: treat dependency acquisition as an endpoint control problem, not only a network control problem.

How postinstall malware turns developer trust into credential theft

Supply chain malware often uses the victim’s own tooling and credentials to expand its reach. In the article’s examples, backdoored packages harvested secrets from cloud and cluster environments, then used legitimate APIs and internal commands to move laterally. That matters because the attacker does not need a separate command channel or exotic exploit chain. They can ride existing developer privileges, access token stores, and automation paths that were intended for software delivery. In practice, the asset being abused is not just the machine, but the trust relationship between the machine, the build pipeline, and the credentials it can reach.

Practical implication: reduce the credential blast radius available to install and build tooling, especially on developer endpoints and CI runners.

Threat narrative

Attacker objective: The attacker wants to steal usable secrets and persist inside developer or build environments by abusing trusted software distribution channels.

1. Entry occurs when an attacker compromises a package account, extension channel, or dependency source and delivers malicious code through a trusted install flow.
2. Credential access follows when the payload reads local secrets, environment files, or cloud tokens exposed to the install or build process.
3. Escalation and lateral movement happen when the malware uses the victim’s own credentials and internal APIs to reach cloud services, cluster resources, or other instances.
4. Impact is credential theft, unauthorized remote code execution, and wider compromise of developer and CI environments through trusted software delivery paths.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time trust is the real control gap: EDR and proxy tooling both assume the dangerous event is visible as an anomaly after or during transit. Supply chain malware breaks that assumption by arriving through approved workflows and then behaving like normal tooling. The governance lesson is that execution trust must be decided at install time, not inferred later from process telemetry.

Developer endpoints now function as credential conduits: The article shows that package compromise is not only a software integrity issue but also a secrets exposure issue. Once a build tool, extension, or runner can reach cloud keys, tokens, or cluster access, the compromise path immediately becomes an identity problem. That is where NHI governance intersects with software supply chain security.

Network-path controls do not define the trust boundary for software delivery: Proxies are useful only when every relevant download and install actually passes through them, which modern developer workflows cannot assume. This shifts the security question from interception to local enforcement, inventory, and execution control. Teams that still treat the proxy as the main supply chain checkpoint are governing the wrong boundary.

Supply chain malware is a privilege problem disguised as a packaging problem: The malicious package does not need to be exotic when the environment already grants broad file access, network access, and secret access during installation. That makes least privilege at the machine and pipeline level the deciding factor, not signature coverage alone. Practitioner takeaway: reduce the privilege attached to every install and build identity.

Developer tooling needs its own governance model: Package managers, editor extensions, and CI runners form a distinct operational tier with different risk characteristics from general-purpose endpoints. Treating them as ordinary user workloads leaves the organisation blind to install-time behaviours that matter most. The control model has to reflect that software delivery is now part of the attack surface, not just the route to it.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Install-time trust is now a governance boundary: Security teams need to stop treating dependency fetches as benign plumbing. The more package managers, editor extensions, and CI runners can execute with ambient secrets, the more the organisation needs local controls that police what gets run before network-based inspection ever matters.

Machine-local enforcement is the decisive control shift: EDR and proxies still have value, but neither is sufficient when the attack executes inside ordinary developer workflows. Practitioners should prepare for a model where install-time policy, secret scoping, and workload identity controls are part of the same governance conversation.

Developer supply chains also intersect with third-party exposure. According to the Ultimate Guide to NHIs 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, which makes dependency trust and credential reach tightly coupled problems.

For practitioners

• Harden developer install paths Restrict what package managers, extension hosts, and build tools can read, execute, and contact during install time so trusted workflows cannot reach broad secrets or arbitrary subprocesses.
• Reduce secret exposure on build systems Move cloud keys, tokens, and other high-value secrets out of endpoints and runners that routinely fetch dependencies, then scope any remaining credentials to the smallest possible task.
• Enforce local execution controls Use on-device controls that inspect install-time behaviour directly, because network proxies cannot protect downloads that bypass them or tools that ignore proxy settings.
• Audit dependency and extension trust paths Inventory where developer tools pull code, how those sources are approved, and which identities can install from them without additional review.

Key takeaways

• Supply chain malware exploits trusted developer workflows, so the security gap is not just malicious code but the approval model that lets that code execute with normal permissions.
• Aikido shows that EDR and proxy controls can miss the attack because the behaviour looks legitimate once install-time execution starts and network paths are inconsistent.
• Practitioners should shift protection toward machine-local enforcement, reduced secret exposure, and tighter control over package, extension, and CI trust paths.

Key terms

• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Endpoint Control Boundary: The practical point where local enforcement must decide what code, files, and network actions are allowed on a machine. For developer supply chains, this boundary is often more important than the network perimeter because malicious actions can occur after the download completes.
• Secret Exposure Surface: Secret exposure surface is the set of places where credentials can be read, copied, or misused by systems and integrations. It includes environment variables, configuration stores, runtime memory, and connected tools. Reducing the surface means limiting both storage and reachability, not just encrypting data at rest.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to modern software delivery and runtime risk.