A maioria das equipes de segurança marca a caixa do EDR, marca a caixa do proxy e segue em frente. Contra malware de supply chain, nenhum oferece proteção significativa porque foram feitos para um problema diferente.
Malware tradicional tem um jeito de se infiltrar em uma máquina, enquanto o malware de supply chain é convidado. O desenvolvedor executa npm install, e o código malicioso chega com permissão total para executar. Essa inversão quebra ambas as ferramentas no nível do design.
Por que o EDR não detecta malware
O EDR monitora processos em busca de comportamento suspeito: chamadas de sistema incomuns, relações pai-filho inesperadas, assinaturas maliciosas conhecidas. Ele pergunta: "Este processo está agindo como malware?"
O problema é que o malware de supply chain é executado dentro de runtimes confiáveis, fazendo coisas que esses runtimes fazem o dia todo. Um script de postinstall que lê arquivos `.env` e envia o conteúdo via POST para um atacante parece idêntico a uma ferramenta de build buscando credenciais para implantar código. Ambos estão node ou python lendo arquivos e fazendo chamadas HTTP. As chamadas de sistema e as chamadas de rede são as mesmas. O EDR não tem contexto de que um é legítimo e o outro não.
Em março de 2026, atacantes sequestraram a conta npm do principal mantenedor do axios, um pacote com ~100M de downloads semanais. Eles não tocaram no código-fonte. Eles adicionaram uma nova dependência cujo único trabalho era um script de postinstall que baixava um RAT multiplataforma e se autoexcluía. Para um monitor de processos, isso era indistinguível do npm install fazendo seu trabalho. Ele resolve uma dependência, executa um hook e faz uma requisição HTTP.
Dois meses depois, três versões do durabletask, um pacote Python no ecossistema Azure da Microsoft, foram backdoored. A injeção tinha cerca de dez linhas em __init__.py. O código busca um arquivo e o executa em um subprocesso, ignorando exceções. A segunda etapa coletou credenciais de AWS, Azure, GCP, Kubernetes e Vault, então se espalhou para outras instâncias via SSM e para outros pods via kubectl exec, usando as próprias credenciais da vítima, atingindo as próprias APIs da Cloud da vítima. Em hosts com configurações de localidade israelense ou iraniana, uma chance em seis executava rm -rf /*. Nenhum binário estrangeiro, nenhum destino anômalo. O EDR não tem um modelo para o caso em que o próprio pacote é a ameaça.
Ataques à Supply chain nesta camada são tão perigosos porque o payload malicioso é um comportamento normal. Não há anomalia para detectar, porque o objetivo é se misturar ao ruído, ou neste caso, ser o ruído.
Por que os proxies não detectam
Um proxy no caminho do tráfego pode interceptar downloads de pacotes e verificá-los contra pacotes maliciosos conhecidos. Isso funciona, em teoria. O problema é a parte "no caminho do tráfego".
Proxies remotos e corporativos são controles opcionais em máquinas que os desenvolvedores possuem. Desenvolvedores trabalham de casa, de cafeterias, de wi-fi de hotel. Eles instalam ferramentas que ignoram as configurações de proxy do sistema. O VS Code gerencia seus próprios downloads de extensões. npm, pip e cargo têm seus próprios clientes HTTP. Muitas ferramentas CLI e runtimes de linguagem ignoram HTTP_PROXY totalmente, a menos que explicitamente configurados. E quando uma ferramenta quebra por causa do proxy, os desenvolvedores desativam o proxy, consertam a ferramenta e esquecem de reativá-lo.
Casos como esses acontecem todos os dias. Um desenvolvedor instala uma extensão comprometida do VS Code às 23h em sua máquina pessoal. Um CI runner puxa uma dependência envenenada fora do perímetro da rede corporativa. Nenhuma dessas instalações passa pelo proxy. A varredura nunca é executada. A verificação que deveria detectá-lo simplesmente não estava lá.
O que realmente funciona
Tanto EDR quanto proxies resolvem problemas reais para as ameaças para as quais foram projetados e ainda são valiosos. Eles simplesmente não cobrem a superfície de ataque da cadeia de suprimentos específica do desenvolvedor.
Essa superfície precisa de algo que resida na própria máquina, entenda o que os pacotes estão fazendo no momento da instalação e esteja sempre presente, independentemente da configuração de rede. Nós construímos o Aikido Device Protection para fazer exatamente isso. Descubra como várias organizações estão usando o Device Protection para proteger máquinas de desenvolvedores neste blog.
Se você quiser uma visão mais completa do que as ferramentas tradicionais de endpoint não detectam em máquinas de desenvolvedores, a versão MDM deste problema é abordada neste artigo.
