Worm ChainDrop envenena 444 pacotes npm e escapa das defesas comuns

Um worm batizado de ChainDrop contaminou 444 pacotes do npm, o repositório de bibliotecas JavaScript que praticamente todo projeto web moderno consome. A variante deriva do Shai-Hulud, família de malware de cadeia de suprimentos que já havia atingido o ecossistema antes, e traz uma diferença desconfortável: ela foi desenhada para escapar das defesas que a maioria das equipes considera suficientes.

Se o seu projeto roda npm install, isso é assunto seu. Não importa se o pacote comprometido é uma dependência direta ou está três níveis abaixo, numa biblioteca que a sua biblioteca usa.

Por que este é diferente

Ataques à cadeia de suprimentos de software não são novidade. O que chama atenção no ChainDrop é o caminho escolhido para se propagar: tarballs e ganchos de ferramentas de desenvolvimento.

Vale destrinchar isso, porque explica por que as defesas usuais não pegaram.

Um pacote npm é distribuído como um tarball — um arquivo compactado com o conteúdo publicado. Boa parte das verificações automatizadas olha para o repositório de código do projeto, não para o conteúdo do pacote efetivamente publicado. Quando os dois divergem, e nada obriga que sejam idênticos, a inspeção do código-fonte não enxerga o que será instalado na sua máquina.

Os ganchos são a segunda metade. O npm executa scripts automaticamente durante a instalação — preinstall, install, postinstall. Isso existe por razões legítimas, como compilar binários nativos. Mas significa que instalar um pacote é executar código, não apenas baixar arquivos. E esse código roda com as permissões de quem rodou o comando.

Num notebook de desenvolvedor, isso costuma incluir acesso a chaves SSH, tokens de nuvem, credenciais salvas e o histórico do shell. Numa esteira de integração contínua, costuma incluir os segredos de deploy.

Por que "a gente audita as dependências" não basta

Aqui está o ponto que muita equipe descobre tarde. As proteções mais comuns têm limites conhecidos:

• Revisar o repositório no GitHub não garante nada sobre o tarball publicado, que pode conter conteúdo diferente.
• Fixar versões no lockfile protege contra atualização inesperada, mas não se a versão que você fixou já estiver comprometida.
• Ferramentas de varredura costumam comparar com listas de vulnerabilidades conhecidas. Um worm novo não está na lista no dia em que aparece.
• Confiar em pacote popular é justamente o vetor: o atacante mira quem tem muitos dependentes, porque o alcance é maior.

Nenhuma dessas práticas é inútil. Elas apenas não cobrem este cenário específico.

O que fazer agora

Há uma medida que corta a maior parte do risco e que quase ninguém aplica por padrão: desligar a execução automática de scripts na instalação.

No npm, isso é npm install --ignore-scripts, e dá para tornar permanente no arquivo de configuração do projeto:

ignore-scripts=true no .npmrc

O custo é real: alguns pacotes precisam do script de instalação para compilar binários nativos e vão quebrar. A prática saudável é ligar o bloqueio por padrão e liberar caso a caso, de forma explícita, apenas para os pacotes que comprovadamente precisam. O pnpm, por sinal, já adota postura mais restritiva nesse ponto, exigindo aprovação explícita para pacotes que rodam scripts.

Além disso, vale, nesta ordem:

1. Verificar se algum pacote da lista comprometida está no seu projeto, incluindo dependências indiretas. npm ls com o nome do pacote resolve, mas o lockfile é a fonte mais confiável.
2. Rodar instalação limpa em ambiente descartável antes de trazer para a máquina principal, se houver suspeita.
3. Rotacionar credenciais que estavam acessíveis na máquina ou na esteira de CI durante a janela de exposição. Isso inclui tokens de nuvem, chaves de deploy e credenciais de banco.
4. Revisar quais segredos a sua esteira de CI expõe a um passo de instalação. Muitas expõem tudo por padrão, quando bastaria expor no passo de deploy.

O ângulo brasileiro: equipe pequena, superfície igual

Um projeto brasileiro típico — agência com cinco a quinze desenvolvedores, atendendo vários clientes — tem a mesma exposição de uma empresa grande, e menos gente para reagir.

Há um agravante próprio desse modelo: quem presta serviço costuma ter, na mesma máquina, credenciais de vários clientes ao mesmo tempo. Um comprometimento no notebook do desenvolvedor não vaza os dados de um projeto — vaza os de todos que estiverem configurados ali.

Isso muda o cálculo de duas práticas que costumam ser adiadas por parecerem burocracia:

• Separar credenciais por cliente e por ambiente, em vez de manter tudo no mesmo arquivo de configuração global.
• Usar credenciais de curta duração sempre que o provedor oferecer, em lugar de chaves permanentes que ficam válidas por anos.

E há a camada legal. Se dados pessoais de clientes forem acessados a partir de um comprometimento assim, a LGPD se aplica normalmente — com obrigação de comunicação e o contrato de prestação de serviço provavelmente prevendo responsabilidade sobre confidencialidade.

O que observar daqui pra frente

O ChainDrop é uma variante, não um caso isolado, e essa é a informação mais relevante. Famílias de malware que se propagam por cadeia de suprimentos vêm sendo iteradas: cada versão testa um vetor que a anterior não usava. A resposta útil não é reagir a cada nome novo, e sim reduzir o que um pacote consegue fazer ao ser instalado.

Vale acompanhar também se registros de pacotes vão adotar verificação obrigatória entre repositório e artefato publicado. Enquanto o tarball puder divergir do código-fonte auditável, a inspeção de repositório continuará dando uma sensação de segurança que ela não entrega.

A pergunta prática para levar à equipe hoje: quantos scripts de instalação rodaram na nossa esteira de CI esta semana, e o que eles tinham permissão de acessar? Se a resposta for "não sei", esse é o primeiro item.