Why EDR and proxies fail against supply chain malware

At a glance

What this is: This is an analysis of why endpoint detection and network proxy controls miss developer-focused supply chain malware that arrives through trusted package installation and extension workflows.

Why it matters: It matters because identity and access assumptions around developer machines, CI runners, and NHI-style credentials collapse when malicious packages inherit the privileges of the trusted user or workload.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.

👉 Read Aikido's analysis of why EDR and proxies miss supply chain malware

Context

Supply chain malware succeeds because it rides a legitimate software installation path rather than breaking in through a noisy exploit. In practice, that means package managers, developer extensions, and CI runners can execute attacker-controlled code with the same trust the environment grants normal build and deployment tooling. For identity and access programmes, the key issue is that the malicious code inherits the privileges of the account or workload that invoked it, including access to secrets, cloud APIs, and internal tooling.

The primary governance gap is assumption mismatch. EDR expects suspicious process behaviour, while proxies expect traffic to traverse a controlled path, but developer workflows often bypass both. That makes this a genuine identity-adjacent problem as well as an endpoint and supply chain issue, because the attacker is abusing authenticated execution rather than stealing a password first.

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 credentials create supply-chain risk beyond repository access?

A: Because those credentials often control release, signing, and marketplace distribution, not just source-code access. If an attacker steals them, they can republish trusted artifacts, inherit legitimate distribution paths, and reach downstream users without breaking perimeter defenses. The risk comes from identity reuse across the software lifecycle, not from source control alone.

Q: How do security teams know whether proxy controls are actually covering developer installs?

A: They test the path, not the policy statement. If a package manager, IDE extension store, or CI runner can reach the internet without passing through the proxy, then the inspection model is incomplete. Practitioners should map every download channel and validate enforcement on each one.

Q: Who is accountable when a poisoned package steals secrets from a build environment?

A: Accountability usually spans platform engineering, security, and the owners of the credential-bearing workflow. If developer tools can bypass central controls, the governance failure is shared. Frameworks such as NIST CSF and NIST SP 800-53 push organisations toward clearer control ownership, especially where machine credentials and software supply chains overlap.

Technical breakdown

Why trusted install paths defeat EDR

EDR is tuned to detect anomalous behaviour after execution begins. Supply chain malware often hides inside normal runtime patterns such as package resolution, postinstall hooks, or plugin loading. A malicious script that reads environment files and makes outbound requests can look identical to legitimate build tooling performing dependency checks or deployment tasks. Because the code runs inside a trusted process tree, process telemetry alone rarely provides enough context to separate malicious package logic from expected developer activity.

Practical implication: classify install-time execution as a control point and monitor package hooks, not just runtime processes.

Why proxy controls fail in developer workflows

Proxy-based controls only help when traffic is forced through them. Developer machines and CI systems frequently use language-native download paths, personal networks, bypassed proxy settings, or tool-specific clients that ignore system-level proxy configuration. That creates an enforcement gap where the inspection point simply is not present. Once the package lands locally, the malicious code can execute before any network-layer control has a chance to intervene.

Practical implication: enforce package and extension control on the endpoint or runner itself, not only at the network boundary.

How supply chain malware turns credentials into lateral movement

Modern supply chain payloads rarely stop at initial execution. They harvest secrets from local files, environment variables, cloud metadata, and vault integrations, then reuse those credentials to move through cloud APIs, storage, build systems, or orchestration layers. That is why these attacks are so damaging in identity terms: the payload does not need to break authentication when it can inherit already-authorised access from the compromised machine or pipeline.

Practical implication: treat developer and CI credentials as high-value NHI assets with strict scope, short lifetime, and rapid revocation paths.

Threat narrative

Attacker objective: The attacker aims to steal reusable credentials and convert trusted developer execution into broader cloud or build-system compromise.

1. Entry occurs when a developer or CI runner installs a poisoned package, extension, or dependency through a trusted workflow such as npm, pip, or a marketplace client.
2. Credential access follows when the payload reads environment files, local tokens, cloud credentials, or vault material that the host already trusts.
3. Escalation and spread happen when the attacker reuses those credentials against cloud APIs, other pods, or adjacent build systems, often using the victim's own access paths.
4. Impact is achieved through credential theft, persistence, destructive actions, or broader supply chain propagation across developer and runtime environments.

NHI Mgmt Group analysis

Supply chain malware is really an identity abuse problem disguised as endpoint malware. The malicious code does not need to defeat authentication when it can run inside an already-authenticated developer session or CI pipeline. That shifts the governance question from detection alone to how much standing access those environments hold. For NHI and IAM teams, developer machines and runners must be treated as privileged execution surfaces, not ordinary endpoints.

Proxy enforcement fails whenever the control is optional. If package managers, extensions, or build tools can bypass the network path, then inspection becomes a best-effort check rather than a governance control. That creates a proxy bypass trust gap: security assumes downloads are mediated, while the toolchain behaves as though they are not. Practitioners should measure which install channels are actually controllable, not which ones policy claims to cover.

EDR alone cannot distinguish legitimate build behaviour from malicious package logic. The same syscalls, subprocesses, and HTTP calls can belong to both a compiler plugin and a payload that steals secrets. This means the defensive boundary has to move earlier, into package provenance, execution policy, and credential scope. The practical conclusion is that endpoint telemetry needs to be paired with install-time enforcement and secrets governance.

Supply chain attacks expose the fragility of broad developer credential scope. When a compromised package can read cloud tokens, kubeconfigs, or vault material, it inherits far more power than the original action required. That is a classic Zero Standing Privilege problem in a developer context. Narrowing token scope and reducing credential lifetime are not hygiene measures here, they are blast-radius controls.

Developer supply chain security is becoming a control-plane issue for identity teams. Package ecosystems now sit inside the operational path that creates, stores, and uses NHI-like credentials. That means IAM, PAM, and secrets governance cannot stop at human accounts. Teams need a shared operating model for machine credentials, install-time trust, and runner identity before the next poisoned dependency lands.

What this signals

Proxy bypass trust gap: the more engineering teams rely on tool-specific download paths, the less meaningful network-only inspection becomes. That shifts programme design toward local enforcement, provenance checks, and tighter control over where code is allowed to execute. The key question is no longer whether the proxy is enabled, but whether the workflow can evade it.

Credential governance now needs to include developer machines and CI runners as first-class privileged environments. When secrets are available to package hooks, extensions, and build scripts, the attack surface looks less like classic malware and more like uncontrolled NHI exposure. That is why OWASP Non-Human Identity Top 10 is relevant here: the same scope, lifetime, and revocation issues show up in machine-driven execution.

The practical signal for security leaders is whether a compromised install can be contained before it touches long-lived credentials. If token scope remains broad and revocation remains slow, the organisation is already assuming attacker persistence. The stronger operating model combines endpoint policy, package provenance, and rapid secret invalidation rather than relying on one control layer.

For practitioners

• Force install-time controls onto endpoints and runners Instrument package managers, extension hosts, and CI runners where the code actually executes. Block or alert on postinstall hooks, unsigned plugins, and dependency downloads that do not pass a local policy check.
• Reduce credential scope on developer and build systems Replace broad environment secrets with narrowly scoped, short-lived credentials. Separate read, write, and deploy permissions so a compromised package cannot reuse one token to reach cloud APIs, orchestration layers, and vaults.
• Track provenance for high-risk package sources Maintain allowlists for package registries, marketplace extensions, and transitive dependency sources used by engineering teams. Prioritise controls on tools that install code outside normal browser-mediated download paths.
• Test revocation speed for exposed secrets Run exercises that assume a malicious package has already copied local credentials. Measure how quickly tokens can be revoked, rotated, and invalidated across cloud, CI/CD, and vault systems.

Key takeaways

• Supply chain malware defeats EDR and proxies by executing inside trusted developer and CI workflows rather than entering as obviously malicious code.
• Credential scope is the real blast-radius variable, because poisoned packages can turn local secrets into cloud and build-system compromise.
• Security teams need local execution policy, provenance controls, and fast revocation for machine credentials if they want meaningful supply chain resilience.

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.
• Proxy Bypass Trust Gap: The gap between a policy that assumes traffic is inspected and a workflow that can avoid the inspection path entirely. It appears when tools use their own network clients, ignore system proxy settings, or operate outside the corporate perimeter, leaving downloads and updates unchecked.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.

What's in the full article

Aikido's full post covers the operational detail this analysis intentionally leaves for the source:

• A walk-through of why install-time malware blends into normal process and network telemetry.
• Specific examples of developer tools and package managers that bypass proxy-based inspection.
• The machine-local protection model Aikido says is needed for developer endpoints and CI runners.
• The article's own comparison of where EDR, proxies, and device-level controls each fail.

👉 Aikido's full post covers the package-install attack path, proxy bypass points, and the endpoint controls it argues are needed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect machine identity, secrets management, and governance decisions across real operating environments.