Você Confia Cegamente no npm install?

Toda vez que o desenvolvedor roda npm install, ele está baixando código de terceiros que executará com as mesmas permissões do seu sistema. Em 2025, o registro de pacotes maliciosos no NPM cresceu 400%, segundo relatório da Sonatype.

Casos Reais Que Abalaram a Indústria

• event-stream (2018): Pacote com 2M+ downloads semanais foi comprometido por um novo maintainer que injetou um módulo para roubar Bitcoin de wallets.
• ua-parser-js (2021): Pacote com 8M+ downloads semanais teve seu account hijacked. Versões maliciosas mineravam cripto e roubavam credenciais.
• Colors.js & Faker.js (2022): O próprio autor sabotou seus pacotes amplamente usados em protesto, quebrando milhares de aplicações.

Vetores de Ataque na Sua Pipeline

• Typosquatting: Criar axois (typo de axios), esperando que alguém erre a digitação.
• Dependency Confusion: Publicar um pacote público com o mesmo nome de um pacote privado interno da empresa. O NPM prioriza o público.
• Maintainer Compromise: Roubar as credenciais NPM de um mantainer legítimo de um pacote popular.
• Build Script Injection: postinstall scripts que executam código arbitrário durante o npm install.

Blindagem da Supply Chain

• npm audit + Snyk/Socket.dev: Auditoria automática de vulnerabilidades conhecidas.
• Lockfile rigoroso: Sempre commite package-lock.json e use npm ci (não npm install) em CI/CD.
• Verificação de integridade: npm config set audit-signatures true.
• Política de dependências: Aprovação formal para adicionar qualquer nova dependência.
• Sandbox de build: CI/CD em containers efêmeros sem acesso a secrets durante o install.
• Pin de versões: NUNCA use "^" ou "~" para dependências críticas.

Na RET, cada dependência é tratada como código não confiável. Rodamos SCA (Software Composition Analysis) automatizado em toda PR, e pacotes novos passam por quarentena antes de entrar na base de código.