Radar Tech: worm no npm envenena centenas de pacotes — hora de tratar dependência como superfície de ataque
Um credential-stealing worm originado no pacote keyv/cacheable se espalhou por centenas de dependências no npm em 4 de agosto e instalou hooks maliciosos em máquinas de dev. O que isso significa para quem decide arquitetura de supply-chain.
Radar Tech desta quarta-feira destaca o incidente de supply-chain que dominou a conversa de segurança: um worm de roubo de credenciais detectado a partir de keyv@6.0.0 se propagou pelo registro npm e envenenou centenas de pacotes em diferentes organizações.
Verificações independentes (SafeDep, Aikido) apontam um footprint amplo e em crescimento: de dezenas de nomes verificados por uma fonte a centenas de pacotes contabilizados por outra — a escala exata ainda é estimada porque o worm se multiplica na própria rede de dependências. O ponto que mais chama a atenção de arquitetos não é apenas o roubo em si, mas o vetor: o payload instala hooks maliciosos em ferramentas de desenvolvimento, como VS Code e agentes de IA tipo Claude Code, que executam quando a máquina do dev abre o projeto.
Ou seja, o ataque não explora uma vulnerabilidade isolada de runtime; ele explora a confiança que damos a uma cadeia inteira de dependências transitivas.
A lição de arquitetura
Incidentes como esse não devem ser respondidos só com a correção de um pacote. Eles expõem uma decisão estrutural que a maioria das bases ainda não tomou: dependência é superfície de ataque e precisa de governança de supply-chain, não de intuição.
Quando um build resolve versões flutuantes, quando não há lockfile determinístico, quando não há mirror corporativo com allowlist e quando não se inspeciona hooks de dev-machine, qualquer pacote transitivo comprometido vira uma porta para exfiltração de credenciais em escala.
A resposta de arquitetura costuma seguir quatro camadas:
- Origem verificada: registry mirror corporativo, assinatura/proveniência e SBOM.
- Resolução determinística: lockfile commitado com integrity hash; sem versões livres.
- Runtime seguro: revisão de hooks (VS Code, Claude Code, git hooks) e varredura de secrets.
- Resposta a incidente: runbook de bloqueio/reversão e rotação de credenciais.
Cada camada é um mecanismo concreto, não uma frase de efeito — e cada decisão de adotar ou não um controle deveria ficar registrada em um ADR rastreável, com consequências, trade-offs e critérios de aceite objetivos.
Para o time de desenvolvimento
- Confirme o que o lockfile fixa hoje: se a resolução é flutuante, corrija antes do próximo incidente.
- Trate hooks de dev-machine como código executável e revise o que é instalado ao abrir o projeto.
- Se suspeitar de exposição, rotacione credenciais e tokens presentes nas máquinas afetadas.
- Formalize a postura de supply-chain como decisão de arquitetura (ADR) e um runbook de resposta.
O incidente do npm é o lembrete de que entregável de software série inclui o tratamento da própria cadeia de fornecimento. Quem aproveita o susto para tirar do papel o zero-trust de dependências sai trabalhando mais seguro — e com decisões documentadas em vez de improviso.
