O npm 12 foi lançado oficialmente com mudanças profundas que priorizam a segurança do ecossistema Node.js. A partir desta versão, os scripts automáticos de instalação passam a vir desativados por padrão, exigindo que os desenvolvedores concedam aprovação explícita para os pacotes nos quais confiam.
- O npm 12 bloqueia scripts de ciclo de vida (pre/post-install) por padrão para combater malwares no ecossistema Node.js.
- As flags --allow-git e --allow-remote passam a vir configuradas como 'none', mitigando vetores que correspondiam a 53% dos ataques recentes.
- Aprovar scripts de pacotes globais ou via npx exigirá configuração explícita de usuário.
- Especialistas manifestam preocupação com a 'fadiga de aprovação' e possíveis travamentos no fluxo inicial de builds (ENOMATCH).
O fim da execução silenciosa de scripts
Historicamente, a instalação de um pacote npm permitia que códigos arbitrários fossem executados no ambiente local através de scripts de ciclo de vida (como preinstall, install e postinstall). Com o lançamento do npm 12, essa facilidade chega ao fim. Agora, a flag allowScripts vem definida como 'off' por padrão, o que significa que nenhum script será disparado de forma automática, incluindo as compilações nativas geradas implicitamente pelo node-gyp.
Essa decisão impacta diretamente fluxos de trabalho tradicionais, exigindo que os times revisem os pacotes pendentes de autorização e salvem uma lista de permissões no arquivo package.json. O GitHub, que mantém o npm, já havia disponibilizado avisos prévios sobre essa mudança a partir da versão 11.16.0 para mitigar quebras bruscas na transição.
# publicidade
Bloqueios adicionais de fontes externas
Além da restrição local, o npm 12 fecha outras brechas importantes contra ataques de cadeia de suprimentos. A configuração --allow-git agora vem definida por padrão como 'none', bloqueando caminhos de execução de código em que dependências baseadas em repositórios Git conseguiam sobrescrever o executável do próprio Git.
Da mesma forma, a flag --allow-remote passou a ser configurada como 'none', impedindo que tarballs HTTP externos sejam puxados automaticamente fora do registro oficial. Em contrapartida, as flags locais --allow-file e --allow-directory mantêm suas regras anteriores sem alteração, já que representam riscos substancialmente menores de injeção externa de código.
As controvérsias e o dilema da fadiga de aprovação
Embora grande parte da comunidade de desenvolvimento JavaScript tenha celebrado a mudança como um avanço tardio contra os malwares, algumas dores de cabeça operacionais foram levantadas por engenheiros de software e especialistas de segurança.
Por um lado, desenvolvedores apontam um problema de 'ovo e galinha': o utilitário de validação (npm approve-scripts) lê o conteúdo de node_modules e gera o erro ENOMATCH se o pacote que precisa ser aprovado ainda não tiver sido fisicamente instalado. Além disso, existe o risco prático de 'fadiga de aprovação'. Analistas de segurança alertam que pacotes extremamente populares e essenciais como esbuild, sharp, core-js e puppeteer dependem criticamente desses scripts. Se builds quebrarem repetidamente, desenvolvedores podem adquirir o hábito de apenas aceitar cegamente as permissões, reduzindo a eficácia real da proteção.
- O comando npm approve-scripts gera erro ENOMATCH se executado antes da presença do pacote no diretório.
- Bibliotecas nativas de renderização ou build continuam quebrando até receberem consentimento formal.
- Riscos de que a aprovação vire um comportamento mecânico sem análise técnica de segurança.
Alinhamento com outros gerenciadores do mercado
Com esta atualização, o npm deixa de ser o único grande gerenciador de pacotes sem esse nível de controle. Ferramentas concorrentes como o pnpm oferecem mecanismos de aprovação de scripts há anos. No quesito proteção por idade mínima de pacotes, enquanto o pnpm adicionou o 'minimumReleaseAge' no patch 10.16 e o Yarn seguiu com o 'npmMinimalAgeGate' na versão 4.10.0, o npm implementou sua própria regra semelhante (min-release-age) apenas na versão 11.10.0.
A relevância dessas medidas se torna ainda mais evidente diante de dados da JFrog, que mostram que scripts de instalação abusivos, repositórios git maliciosos e tarballs não oficiais representaram cerca de 53% de todos os vetores de ataques direcionados ao registro do npm observados no ano passado.
| Recurso / Flag | Comportamento Antigo (Até npm 11) | Comportamento Novo (npm 12) | Impacto de Segurança |
|---|---|---|---|
| allowScripts | Ativado (on) por padrão | Desativado (off) por padrão | Impede execução de códigos maliciosos não revisados no terminal local. |
| --allow-git | Permitia uso dinâmico de executável | Configurado como 'none' por padrão | Evita injeção de comportamento alternativo na leitura de repositórios Git. |
| --allow-remote | Instalava tarballs diretos via HTTPS | Configurado como 'none' por padrão | Bloqueia download automático de fontes não homologadas. |
Arraste para o lado para ver toda a tabela.
