Melhores Práticas de Segurança do npm

Mar 28, 2026 · 4 min read

O ecossistema npm é o maior registro de pacotes do mundo, e essa escala o torna um alvo de alto valor. Ataques como Shai-Hulud, event-stream e eslint-scope demonstraram a mesma verdade desconfortável: instalar um pacote pode executar código arbitrário em sua máquina antes mesmo de você ler uma única linha do código-fonte. Estas melhores práticas de segurança do npm ajudam você a reduzir esse risco em cada etapa—instalação, desenvolvimento e publicação.

Principais Conclusões

Desabilite scripts pós-instalação globalmente e adicione à lista de permissões apenas os pacotes que realmente precisam deles.
Defina um período de espera para novas versões, para que versões recém-lançadas (e potencialmente maliciosas) nunca cheguem às suas builds automaticamente.
Sempre faça commit do seu lockfile e use npm ci em pipelines de CI para instalações reproduzíveis e resistentes a adulterações.
Proteja contas de mantenedores com 2FA baseado em WebAuthn e publique via trusted publishing OIDC para eliminar tokens de longa duração.

Por Que a Segurança da Cadeia de Suprimentos do npm Importa Agora

Ataques à cadeia de suprimentos não exploram seu código. Eles exploram sua confiança no código de terceiros. Quando um pacote comprometido chega ao seu node_modules, ele pode roubar credenciais, exfiltrar variáveis de ambiente ou se propagar ainda mais. Somente o worm Shai-Hulud provocou a remoção de mais de 500 pacotes do registro em um único incidente. Varredura de vulnerabilidades por si só não detecta essa classe de ataque—você precisa de defesa em profundidade.

Gerenciamento Seguro de Dependências: Fortaleça Suas Instalações

Desabilite Scripts Pós-Instalação

Scripts pós-instalação são o vetor de ataque mais comum em ataques à cadeia de suprimentos do npm. Desabilite-os globalmente:

npm config set ignore-scripts true
npm config set allow-git none   # npm CLI 11.10.0+

A configuração allow-git=none é importante porque uma dependência baseada em git pode trazer seu próprio .npmrc que reabilita silenciosamente scripts de ciclo de vida, contornando completamente o ignore-scripts.

Se você usa pnpm, a versão 10+ desabilita scripts pós-instalação por padrão. Use pnpm-workspace.yaml para adicionar explicitamente à lista de permissões os pacotes que legitimamente precisam deles:

allowBuilds:
  esbuild: true
  core-js: false

Habilite strictDepBuilds: true para transformar qualquer script de build não revisado em uma falha que bloqueia o CI, em vez de um aviso silencioso. Bun também bloqueia scripts pós-instalação por padrão, com opt-in via trustedDependencies no package.json.

Quando você realmente precisar de scripts de ciclo de vida, use @lavamoat/allow-scripts para criar uma lista de permissões auditável em vez de habilitar scripts globalmente.

Adicione um Período de Espera para Novas Versões

Pacotes maliciosos são frequentemente descobertos e removidos em questão de horas ou dias. Ignorar versões recém-lançadas dá à comunidade tempo para detectar problemas antes que eles cheguem até você:

npm config set min-release-age 3

Isso instrui o npm a ignorar qualquer versão de pacote publicada há menos de três dias. Para atualizações automatizadas de dependências, ferramentas como Renovate e Dependabot suportam configurações equivalentes de minimumReleaseAge.

Faça Commit do Seu Lockfile e Use `npm ci`

Sempre faça commit do package-lock.json. Em ambientes de CI, substitua npm install por:

npm ci

npm ci instala exclusivamente a partir do lockfile, falha se houver qualquer incompatibilidade e nunca resolve silenciosamente uma versão diferente. Esta é a base de builds reproduzíveis e seguros em pipelines automatizados.

Não Atualize às Cegas

npm audit e npm outdated são sinais úteis, mas trate-os como uma entrada, não como uma solução completa. Antes de atualizar qualquer dependência, revise o changelog. Evite atualizações em massa que pulem esta etapa—cada atualização de versão é uma potencial mudança na superfície de ataque.

Fluxos de Trabalho Seguros do npm para Mantenedores de Pacotes

Habilite 2FA—e Migre para WebAuthn

Sequestros de conta são o principal mecanismo por trás de ataques à cadeia de suprimentos no registro. Habilite 2FA em sua conta npm com proteção em modo de escrita:

npm profile enable-2fa auth-and-writes

O GitHub cada vez mais incentiva passkeys e autenticação baseada em WebAuthn, que são significativamente mais resistentes a phishing do que o 2FA tradicional baseado em TOTP. Uma chave de hardware ou passkey é significativamente mais difícil de ser alvo de phishing do que um código TOTP, então migrar mais cedo do que tarde vale a pena.

Publique com Trusted Publishing (OIDC)

Tokens npm de longa duração são uma vulnerabilidade. Trusted publishing via OIDC permite que GitHub Actions ou GitLab CI se autentiquem diretamente com o npm usando credenciais de curta duração e com escopo de fluxo de trabalho—nenhum token armazenado necessário. Também gera automaticamente atestações de proveniência, fornecendo aos consumidores prova criptográfica de onde e como um pacote foi construído.

Esta é a direção para onde o ecossistema está caminhando. O GitHub sinalizou planos para descontinuar tokens legados e tornar o trusted publishing o caminho padrão para automação.

Verifique o Que Você Instala

Não presuma que o registro oficial é seguro. Use Socket ou npq para verificar pacotes em busca de comportamento suspeito antes da instalação. Verifique contagens de download, atividade do repositório e histórico do mantenedor—especialmente para pacotes sugeridos por assistentes de codificação com IA, que podem alucinar nomes de pacotes que atacantes então registram (uma técnica chamada slopsquatting).

Conclusão

Nenhuma ferramenta única previne todos os ataques à cadeia de suprimentos do npm. As práticas que mais importam são em camadas: desabilite scripts de ciclo de vida, imponha lockfiles, adicione um período de espera para novas versões, use npm ci em CI e mova a publicação para OIDC com 2FA. Cada camada reduz o risco independentemente. Juntas, elas tornam seu fluxo de trabalho significativamente mais difícil de comprometer.

Perguntas Frequentes

Sim, alguns pacotes como esbuild ou sharp requerem scripts pós-instalação para baixar binários específicos da plataforma. Em vez de reabilitar scripts globalmente, use uma abordagem de lista de permissões com a configuração allowBuilds do pnpm ou allow-scripts do LavaMoat para conceder permissão apenas a pacotes específicos e confiáveis que genuinamente precisam de etapas de build.

Não. npm audit verifica vulnerabilidades conhecidas em avisos publicados, mas não pode detectar novos ataques à cadeia de suprimentos como typosquatting, sequestros de conta ou código malicioso injetado em pacotes legítimos. Trate audit como um sinal útil dentro de uma estratégia de defesa em camadas mais ampla que inclui imposição de lockfile, restrições de scripts e ferramentas de verificação pré-instalação.

npm install lê o package.json, resolve intervalos de dependências e pode modificar o lockfile. npm ci lê apenas do package-lock.json, instala versões exatas e falha imediatamente se o lockfile estiver ausente ou inconsistente com o package.json. Sempre use npm ci em pipelines de integração contínua para garantir builds reproduzíveis e resistentes a adulterações.

Tokens npm tradicionais são segredos de longa duração armazenados em ambientes de CI, tornando-os alvos atraentes para roubo. Trusted publishing OIDC gera credenciais de curta duração com escopo de fluxo de trabalho vinculadas a um repositório e execução de ação específicos. Nenhum segredo é armazenado em lugar algum, e cada operação de publicação é criptograficamente vinculada à sua origem, produzindo atestações de proveniência verificáveis automaticamente.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.