O GitHub está prestes a provocar uma das mudanças de segurança mais relevantes do ecossistema JavaScript nos últimos anos. Portanto, se você ainda não leu sobre o npm 12, este é o momento certo para entender o que está em jogo antes de julho chegar.

GitHub e o problema que ninguém queria admitir

Por muito tempo, a execução automática de scripts durante o npm install funcionou como uma porta aberta no meio de um cofre. Afinal, cada pacote instalado, incluindo todas as suas dependências transitivas, tinha permissão para rodar código arbitrário na sua máquina ou no seu servidor de CI/CD.

Isso significa que um único pacote comprometido, enterrado três camadas abaixo na sua árvore de dependências, já era suficiente para comprometer todo o ambiente. O worm Shai-Hulud é um exemplo concreto desse vetor de ataque em ação. Assim, a vulnerabilidade não era hipotética; ela já estava sendo explorada ativamente.

Como apontou o mantenedor Leo Balter, os scripts de ciclo de vida representam a maior superfície de execução de código em todo o ecossistema npm. Logo, a decisão de agir sobre isso não foi surpresa, mas chegou tarde.

O que o GitHub muda de vez no npm 12

A versão 12, prevista para julho de 2026, chega com três alterações que impactam o comportamento padrão da ferramenta:

Scripts de ciclo de vida bloqueados por padrão. Configurações em preinstall, install e postinstall não executam mais automaticamente. Para permitir um script específico, é necessário declará-lo explicitamente via allow-scripts.

Download via Git desativado. A flag allow-git passa a ser desabilitada por padrão. Consequentemente, isso elimina o vetor onde um arquivo .npmrc malicioso poderia sobrescrever o executável do Git e redirecionar a execução.

Dependências remotas bloqueadas. A flag allow-remote agora assume o valor none por padrão. Em outras palavras, dependências não podem mais ser baixadas de origens externas sem autorização explícita.

O que você provavelmente vai precisar revisar antes do lançamento do npm 12

Se o seu projeto usa módulos nativos compilados em tempo de instalação, ou ferramentas como Playwright, Puppeteer e Electron, você vai encontrar quebras. Essas ferramentas dependem de scripts postinstall para baixar binários, portanto precisarão de uma allowlist configurada no package.json.

Além disso, existe um detalhe importante sobre conflito de configuração. Se você já tem ignore-scripts definido como true no seu ambiente, ele vai sobrescrever a nova configuração allow-scripts. Sendo assim, remova o ignore-scripts antes de adotar o novo padrão, caso contrário as allowlists que você configurar serão ignoradas.

A recomendação atual é começar a ajustar essas flags no .npmrc ou via variáveis de ambiente ainda agora, antes da chegada da versão 12.

Isso resolve o problema de vez?

Não completamente. Parte da comunidade já sinalizou que essa mudança, embora necessária, não fecha todas as brechas. Na prática, um malware pode simplesmente mover o código malicioso do script de instalação para dentro do próprio módulo, que ainda executa normalmente.

Vale mencionar, aliás, que gerenciadores como pnpm, Yarn Berry, Bun e Deno já implementavam essas restrições por padrão há bastante tempo. Portanto, o npm está, essencialmente, alcançando um padrão de segurança que parte do ecossistema já considerava básico.

GitHub e a cadeia de suprimentos: o que fazer agora

A mudança é um breaking change real. Então, em vez de esperar julho chegar para descobrir o que quebrou, o caminho mais inteligente é auditar agora quais pacotes no seu projeto dependem de scripts de ciclo de vida, montar a allowlist correspondente e testar o comportamento com as novas flags ativas.

Segurança na cadeia de suprimentos não é um problema que se resolve com uma única atualização. No entanto, remover a execução automática de scripts arbitrários da equação é, sem dúvida, um passo na direção certa.

Acompanhe nosso perfil no Instagram!