Notifications
Clear all
Topic starter
02/08/2026 11:30 am
TL;DR: Supply chain malware can execute inside trusted install flows, which makes EDR and proxy controls ineffective when package managers, extensions, or CI runners fetch poisoned dependencies, according to Aikido. The control gap is not visibility alone but machine-local enforcement that understands install-time behaviour and remains present regardless of network path.
NHIMG editorial — based on content published by Aikido: Why EDR and proxy won’t save you from supply chain malware
By the numbers:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.
Questions worth separating out
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.
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.
Q: How do security teams know whether proxy controls are actually covering developer installs?
A: They test the path, not the policy statement.
Practitioner guidance
- Force install-time controls onto endpoints and runners Instrument package managers, extension hosts, and CI runners where the code actually executes.
- Reduce credential scope on developer and build systems Replace broad environment secrets with narrowly scoped, short-lived credentials.
- Track provenance for high-risk package sources Maintain allowlists for package registries, marketplace extensions, and transitive dependency sources used by engineering teams.
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.
👉 Read Aikido's analysis of why EDR and proxies miss supply chain malware →
Supply chain malware in developer tools: what protections actually work?
Explore further
02/08/2026 12:45 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Why EDR and proxies fail against supply chain malware
