NPM 12 Acaba com a Scriptpocalipse

`npm 12` finalmente fecha a porta para o faroeste da instalação de pacotes, encerrando uma era perigosa onde `npm install` funcionava como uma farra silenciosa de execução de código. Por anos, scripts `pre-install` e `post-install`, juntamente com seus equivalentes `install`, eram executados automaticamente para cada dependência, transformando uma tarefa rotineira no principal vetor para ataques insidiosos à cadeia de suprimentos. Este comportamento padrão transformou uma simples obtenção de pacote em uma aposta de alto risco.

Um modelo de confiança implícita sustentava todo o ecossistema JavaScript, permitindo que qualquer pacote executasse código arbitrário durante a instalação sem o consentimento explícito do usuário. Atacantes exploraram magistralmente esse ponto cego. O worm auto-propagante Shai-Hulud, por exemplo, comprometeu centenas de pacotes para exfiltrar credenciais e se espalhar autonomamente, enquanto sua variante "Mini Shai-Hulud" de maio de 2026 mirou projetos proeminentes como `TanStack` explorando GitHub Actions.

A comunidade debateu essa vulnerabilidade crítica por anos, dividida entre necessidades urgentes de segurança e o imenso desafio de manter a compatibilidade retroativa em um ecossistema vasto e dependente de scripts. Agora, o `npm 12` corta esse nó górdio. Ele desativa a execução automática de scripts por padrão, forçando um fluxo de aprovação explícito via `npm approve-scripts`. Essa mudança há muito esperada, da confiança implícita para a lista de permissões explícita, finalmente prioriza a segurança, inaugurando um futuro mais seguro, ainda que ligeiramente menos conveniente.

O `npm install` na versão 12 não executa mais cegamente código arbitrário de suas dependências. Os dias de scripts `pre-install`, `install` e `post-install` sendo executados por padrão acabaram definitivamente, encerrando um vetor crítico para ataques à cadeia de suprimentos como Shai-Hulud e os recentes comprometimentos de TanStack. Este bloqueio abrangente se estende até mesmo a builds nativas essenciais de `node-gyp` e scripts `prepare` originados de dependências Git, de arquivo ou de link, neutralizando efetivamente qualquer execução de código inesperada antes que ela comece.

Apresentamos `npm approve-scripts`, seu novo guardião. Este comando introduz um fluxo de trabalho explícito e auditável, capacitando os desenvolvedores a revisar cada script e habilitar seletivamente apenas aqueles em que realmente confiam. Uma vez aprovadas, o `npm` armazena essas permissões diretamente em seu arquivo `package.json`, criando um registro transparente e versionado do código permitido que é executado durante a instalação. Isso substitui a automação perigosa anterior por um consentimento deliberado e informado.

Isso não é meramente um novo comando; é uma profunda mudança filosófica para todo o ecossistema JavaScript. O `npm` move-se decisivamente de um modelo de confiança implícita – onde qualquer dependência poderia executar qualquer coisa – para um de lista de permissões explícita. Os desenvolvedores recuperam controle absoluto e granular sobre precisamente qual código é executado em suas máquinas, transformando o `npm install` de uma potencial responsabilidade em uma operação deliberada e segura. A scriptpocalipse termina não com um lamento, mas com um "Não" firme e auditável.

Embora os scripts `pre-install` e `post-install` fossem os vetores mais chamativos para ataques à cadeia de suprimentos, adversários astutos nunca colocaram todos os seus ovos na mesma cesta. Eles também aproveitaram caminhos menos óbvios, como Git dependencies diretas e tarballs de URL remotos, para infiltrar código malicioso em projetos desavisados. Atacantes exploraram famosamente esses métodos em incidentes como a variante Mini Shai-Hulud que visou pacotes sob o namespace TanStack, frequentemente injetando arquivos `.npmrc` maliciosos através dessas rotas indiretas.

O npm 12 fecha essas portas secundárias com um mandato simples e explícito. Os desenvolvedores agora devem usar `--allow-git` para resolver dependências baseadas em Git e `--allow-remote` ao instalar pacotes de tarballs baseados em URL. Isso não é apenas um inconveniente; é um ponto de atrito crítico projetado para forçar decisões conscientes, eliminando a confiança implícita em fontes externas e reduzindo significativamente a superfície de ataque.

Ninguém poderá alegar ignorância quando o npm 12 for lançado em julho; avisos para essas breaking changes estão ativos desde o npm v11.16.0+. Este período de carência oferece ampla oportunidade para as equipes auditarem seus pipelines de build e atualizarem as declarações de dependência, evitando interrupções repentinas. Para mais detalhes sobre as próximas mudanças, consulte o Upcoming breaking changes for npm v12 - GitHub Changelog.

Finalmente, o npm reconhece a realidade. A execução descontrolada de scripts, um vetor primário para ataques à cadeia de suprimentos, está terminando com o npm 12 após anos de exploração generalizada. Essa mudança há muito esperada para a aprovação explícita de scripts, finalmente alcançando alternativas mais conscientes da segurança, transforma `npm install` de um exercício de confiança ingênuo em uma operação protegida. É uma evolução necessária, embora chegue em julho de 2026, anos depois de os primeiros alarmes soarem.

Mesmo com essas mudanças bem-vindas, a batalha pela integridade da cadeia de suprimentos continua. Muitos especialistas em segurança, incluindo eu, simplesmente defendem o uso do pnpm, que possui padrões superiores, como o bloqueio de sub-dependências exóticas e o atraso na adoção de novos pacotes. A postura proativa do pnpm, que há muito tempo defende uma postura mais restritiva e segura por padrão, oferece uma alternativa atraente para projetos que exigem proteção imediata e robusta.

Essas atualizações reduzem significativamente a superfície de ataque, restringindo os vetores de script `pre-install` e `post-install` que alimentaram incidentes como Shai-Hulud e o comprometimento do TanStack. O bloqueio explícito de Git dependencies e tarballs remotos fecha ainda mais caminhos de ataque bem conhecidos. No entanto, os atacantes são implacavelmente adaptáveis. Espere uma mudança para outras vulnerabilidades, talvez explorando arquivos `.npmrc` maliciosos, configurações incorretas de CI/CD ou engenharia social sofisticada. A vigilância do desenvolvedor, examinando cada dependência e processo de build, permanece o firewall definitivo e indispensável neste cenário de ameaças em evolução.

Qual é a maior mudança no NPM 12?

A mudança mais significativa é que `npm install` não executará mais automaticamente scripts pre-install, install ou post-install para dependências. Os usuários agora devem aprová-los explicitamente.

Como faço para executar scripts para dependências confiáveis no NPM 12?

Você precisa usar o novo comando `npm approve-scripts`. Isso solicitará que você aprove scripts de suas dependências, e suas seleções serão salvas em seu package.json.

Por que o NPM está fazendo essas mudanças de segurança agora?

Estas mudanças são uma resposta direta a uma onda de ataques sofisticados à cadeia de suprimentos, como o worm Shai-Hulud, que exploraram a execução automática de scripts para roubar credenciais e espalhar malware.

Outros gerenciadores de pacotes como PNPM ou Yarn já são tão seguros?

Sim, outros gerenciadores de pacotes como PNPM e Yarn já implementaram comportamentos de segurança por padrão semelhantes, como o bloqueio de scripts de instalação automáticos, há algum tempo.