DEV Community

Cover image for Como proteger dependências NPM? Guia completo de segurança da cadeia de suprimentos para desenvolvedores de API
Lucas
Lucas

Posted on • Originally published at apidog.com

Como proteger dependências NPM? Guia completo de segurança da cadeia de suprimentos para desenvolvedores de API

Resumo

Os ataques à cadeia de suprimentos do NPM aumentaram para mais de 3.000 pacotes maliciosos somente em 2024, e o comprometimento do Axios em março de 2026 provou que nem mesmo os 10 principais pacotes estão seguros. Este guia traz, de forma prática, todas as camadas de defesa que desenvolvedores de API devem implementar: lockfile obrigatório, scripts postinstall bloqueados, verificação de proveniência, ferramentas de análise comportamental e decisões arquiteturais que reduzem a superfície de ataque.

Experimente o Apidog hoje

Introdução

O ataque à cadeia de suprimentos do Axios em 31 de março de 2026 não foi o primeiro comprometimento do npm, e não será o último. Com 83 milhões de downloads semanais e um RAT multiplataforma injetado por meio de uma conta de mantenedor sequestrada, foi o maior alerta já visto pelo ecossistema JavaScript.

O diferencial desse ataque em relação ao conselho padrão (“atualize suas dependências”) é que ele ignorou todas as defesas tradicionais. O código malicioso não estava no próprio Axios, mas em uma dependência fantasma disparando um hook postinstall. Lockfiles não ajudaram se você rodou npm install na janela do ataque. Fixação de versão não adiantou se você não havia travado antes.

Desenvolvedores de API estão especialmente expostos: scripts de teste, pipelines CI/CD, servidores mock e clientes HTTP usam npm. Um pacote comprometido pode vazar chaves de API, credenciais e tokens de nuvem.

💡 Apidog elimina um vetor crítico ao fornecer cliente HTTP integrado para testes de API, dispensando Axios, node-fetch ou got na sua stack de testes. Reduza sua superfície de dependências npm usando o Apidog enquanto implementa as estratégias abaixo.

Este guia cobre sete camadas de defesa, do lockfile básico à análise comportamental avançada.

Camada 1: Imposição de lockfile

Por que lockfiles importam

Um lockfile grava a versão exata de cada pacote e dependência transitiva. Sem lockfile, npm install pega a versão mais recente no intervalo semver. Se seu package.json diz "axios": "^1.14.0" e existe uma 1.14.1 maliciosa, você instala a versão maliciosa.

Prática recomendada

  • Sempre versionar seu lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lock).
  • No CI/CD, use instalações congeladas. Nunca rode npm install puro em ambientes automatizados. Use: 
# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile
Enter fullscreen mode Exit fullscreen mode
  • Revise diffs do lockfile em PRs. Ao alterar package-lock.json, confira novas dependências, upgrades e URL dos registros. Ferramentas como Socket.dev automatizam alertas de alterações suspeitas.

Limitação

Lockfiles só protegem contra resolução inesperada de versão após a primeira instalação. Se você inicializa/instala um pacote durante uma janela de ataque, o malicioso será travado. Por isso, lockfile é a base, não o único pilar.

Camada 2: Desative scripts postinstall

Vetor de ataque mais comum

O ataque do Axios, ua-parser-js, event-stream, entre outros, usaram scripts postinstall para rodar código arbitrário durante npm install, antes de qualquer revisão ou proteção em runtime.

Como bloquear scripts globalmente

Adicione ao seu .npmrc:

ignore-scripts=true
Enter fullscreen mode Exit fullscreen mode

Ou via CLI:

npm config set ignore-scripts true
Enter fullscreen mode Exit fullscreen mode

Isso bloqueia todos os scripts (preinstall, install, postinstall, prepare) nas instalações.

Como lidar com pacotes legítimos que exigem scripts

  1. Execute scripts seletivamente após instalar: 
npm ci --ignore-scripts
npm rebuild bcrypt sharp
Enter fullscreen mode Exit fullscreen mode
  1. Permita scripts apenas para pacotes confiáveis (npm 10+):

.scriptsrc.json:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}
Enter fullscreen mode Exit fullscreen mode
  1. Prefira binários pré-construídos: Muitos pacotes, como sharp, já distribuem binários prontos. Verifique suas dependências e minimize exceções.

Atenção ao PackageGate

Em janeiro de 2026, o PackageGate mostrou que dependências baseadas em Git podem executar código mesmo com scripts desativados. Se usar dependências Git, fixe em hashes de commit e audite o repositório.

Camada 3: Fixe versões exatas

Não use intervalos semver

Por padrão, npm install --save adiciona:

{
  "axios": "^1.14.0"
}
Enter fullscreen mode Exit fullscreen mode

O ^ aceita qualquer 1.x.x mais recente. Para travar:

{
  "axios": "1.14.0"
}
Enter fullscreen mode Exit fullscreen mode

No .npmrc:

save-exact=true
save-prefix=''
Enter fullscreen mode Exit fullscreen mode

Substitua dependências transitivas

Para dependências de terceiro nível, use overrides (npm/pnpm) ou resolutions (Yarn):

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

pnpm:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Trade-off

Fixar versões exige updates manuais. Você ganha controle e previsibilidade, ao custo de mais manutenção — essencial para projetos críticos em segurança.

Camada 4: Verifique a proveniência do pacote

O que é proveniência

Proveniência vincula o pacote ao repositório de origem e ambiente de build, usando assinaturas Sigstore. Isso prova:

  • De qual repositório saiu
  • Qual CI/CD construiu
  • Qual commit gerou o build

Como verificar 

npm audit signatures
Enter fullscreen mode Exit fullscreen mode

Pacotes publicados manualmente não têm proveniência — um sinal de risco.

Como habilitar nos seus próprios pacotes

No CI/CD:

- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Enter fullscreen mode Exit fullscreen mode

No .npmrc:

provenance=true
Enter fullscreen mode Exit fullscreen mode

Limitações

A maioria dos pacotes ainda não tem proveniência; ela só prova o local de build, não a segurança do código-fonte. Pipelines comprometidos podem gerar pacotes maliciosos com proveniência válida.

Camada 5: Use ferramentas de análise comportamental

Vá além do npm audit

Ferramentas tradicionais (npm audit, Snyk) só detectam CVEs públicos. Ataques zero-day (como o do Axios) não estão em nenhum CVE.

Ferramentas comportamentais analisam o que o pacote faz.

Socket.dev

O Socket analisa comportamento do pacote durante instalação e execução, sinalizando:

  • Requisições de rede durante install
  • Escrita/leitura fora do diretório do pacote
  • Execução de shell
  • Coleta de variáveis de ambiente
  • Código ofuscado

Alerta do Socket

No GitHub, o Socket comenta em PRs com alertas. A dependência maliciosa do ataque Axios teria sido flagrada por múltiplos critérios.

# Instale Socket CLI
npm install -g @socketsecurity/cli

# Analise seu projeto
socket scan
Enter fullscreen mode Exit fullscreen mode

Snyk

Foca em vulnerabilidades conhecidas, pontuação de risco e orientação de correção.

npm install -g snyk
snyk test
Enter fullscreen mode Exit fullscreen mode

Exemplo Snyk

Estratégia em camadas

Use todos:

npm audit
socket scan
snyk test
Enter fullscreen mode Exit fullscreen mode

Execute no CI/CD. Qualquer falha crítica deve bloquear o build.

Camada 6: Minimize sua superfície de dependência

Por que reduzir dependências

Cada pacote é uma decisão de confiança. O projeto Node.js médio tem centenas de dependências transitivas. Menos pacotes, menos vetores de ataque.

Audite sua árvore 

# Conte dependências totais
npm ls --all | wc -l

# Veja duplicatas mais comuns
npm ls --all | sort | uniq -c | sort -rn | head -20
Enter fullscreen mode Exit fullscreen mode

Pergunte para cada dependência:

  • Já existe nativamente no Node.js?
  • Traz dezenas de sub-dependências?
  • Pode ser feito “vendor” do código (copiar para o projeto)?

Alternativas nativas para pacotes comuns

Pacote Alternativa nativa Desde
axios, node-fetch, got fetch (global) Node.js 18
uuid crypto.randomUUID() Node.js 19
dotenv --env-file flag Node.js 20.6
chalk util.styleText() Node.js 21.7
glob fs.glob() Node.js 22
path-to-regexp Native URL pattern API Node.js 23

Para testes de API

Workflows de teste de API normalmente usam várias libs (cliente HTTP, asserção, runner, mock). Cada uma é um risco.

Test stack

O Apidog substitui toda essa stack:

  • Cliente HTTP: Integrado, sem npm extra
  • Asserções: Builder visual integrado
  • Test runner: Automatiza cenários, integra CI/CD via CLI
  • Mock server: Mock dinâmico sem Express ou libs de terceiros
  • Documentação: Gerada automaticamente

Migrar seu teste de API para o Apidog elimina dezenas de dependências npm. Menos dependências = menos ataque.

Experimente o Apidog gratuitamente para consolidar sua stack de testes de API.

Camada 7: Monitoramento de rede e runtime

Bloqueie domínios maliciosos conhecidos

Após um ataque, bloqueie C2 servers no nível do sistema:

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
Enter fullscreen mode Exit fullscreen mode

No CI/CD, restrinja a rede de saída ao mínimo necessário (registro npm, repositório Git, destinos de deploy).

Use StepSecurity Harden-Runner no CI/CD

O Harden-Runner monitora workflows GitHub Actions em tempo real. Detecta contatos maliciosos em segundos. Entrega:

  • Monitoramento de rede de saída
  • Rastreamento de processos filhos
  • Monitoramento de integridade de arquivos
  • Alertas automáticos de comportamento anômalo 
# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # ou 'block'
Enter fullscreen mode Exit fullscreen mode

Monitoramento de processo em runtime

No dev, use EDRs que sinalizam processos filhos suspeitos do Node.js (osascript, cscript, python3). O RAT do Axios usava esse padrão — detectável via monitoramento de processo.

Configuração .npmrc recomendada

Aqui está um .npmrc seguro para versionar no seu projeto:

# Fixar versões exatas
save-exact=true
save-prefix=

# Desabilitar scripts
ignore-scripts=true

# Habilitar proveniência
provenance=true

# Usar registro oficial
registry=https://registry.npmjs.org/

# Exigir 2FA
auth-type=web

# Auditoria mínima
audit-level=moderate
Enter fullscreen mode Exit fullscreen mode

Comite no repositório para padronizar as configurações de segurança da equipe.

Exemplo de pipeline de segurança CI/CD

Workflow GitHub Actions impondo todas as 7 camadas:

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # Camada 1+2: Lockfile congelado, sem scripts
      - run: npm ci --ignore-scripts

      # Camada 3: Verificar versões inesperadas
      - run: npm ls --all > deps.txt

      # Camada 4: Verificar proveniência
      - run: npm audit signatures

      # Camada 5: Análise comportamental
      - run: npx socket scan

      # Camada 5: Varredura de vulnerabilidades
      - run: npx snyk test

      # Camada 1: Auditoria de linha de base
      - run: npm audit --audit-level=moderate

      # Reconstruir apenas dependências nativas permitidas
      - run: npm rebuild sharp bcrypt
Enter fullscreen mode Exit fullscreen mode

O que vem a seguir para a segurança do npm

Proveniência obrigatória

O npm avalia exigir proveniência para pacotes populares, impedindo publicações manuais com token, como no ataque do Axios.

Aprovação por dois mantenedores

Lançamentos de pacotes muito baixados podem exigir aprovação dupla, reduzindo o risco de comprometimento por conta única.

Permissões em tempo de execução

Deno já restringe scripts por permissões explícitas (rede, FS, env). Node.js estuda modelo semelhante, exigindo permissões explícitas para scripts postinstall.

Isolamento mais rígido

O modelo de isolamento do pnpm (acesso só a dependências declaradas) previne confusões. O npm caminha para rigidez similar.

Perguntas Frequentes

O que é um ataque à cadeia de suprimentos no npm?

Ataques à cadeia de suprimentos comprometem dependências, não o app diretamente. O atacante injeta código malicioso em pacotes populares, publica typosquats ou sequestra contas de mantenedores. Ao instalar/atualizar, o código malicioso executa, podendo roubar credenciais, instalar backdoors ou exfiltrar dados.

npm audit é suficiente?

Não. Ele só verifica CVEs públicos. Ataques zero-day não aparecem em bancos de dados. Use ferramentas comportamentais (Socket.dev) para inspecionar o que o pacote faz. npm audit é baseline, não defesa completa.

Preciso abandonar o npm?

Não. O npm é vasto e a maioria dos pacotes é segura. Reduza exposição: fixe versões, imponha lockfile, bloqueie scripts, minimize dependências e prefira alternativas nativas sempre que possível.

Como o Apidog reduz riscos na cadeia do npm?

O Apidog oferece cliente HTTP, executor de testes, servidor mock e gerador de documentação integrados, eliminando necessidade de Axios, node-fetch, Jest, Express e diversas dependências de teste. Menos dependências, menos risco.

O que é proveniência de pacote no npm?

Proveniência vincula um pacote ao repositório e build CI/CD via Sigstore. Você pode verificar com npm audit signatures. Pacotes publicados manualmente (sem proveniência) são suspeitos, especialmente se populares.

Quantos pacotes npm são maliciosos?

Snyk registrou mais de 3.000 pacotes maliciosos em 2024. No Q4/2025, a Sonatype bloqueou 120.612 ataques de malware em npm, PyPI e outros. A maioria são typosquats de baixo download, mas ataques high-profile como o do Axios mostram que nenhum pacote é imune.

O que é PackageGate?

Conjunto de seis zero-days divulgados em jan/2026, afetando npm, pnpm, vlt e Bun. Dependências Git podem executar código mesmo com scripts desativados. Por isso, fixe dependências Git em hashes específicos e audite o conteúdo.

Principais conclusões

  • Imponha lockfile, mas saiba que não protege a primeira instalação em janela de ataque.
  • Desative scripts postinstall globalmente com ignore-scripts=true no .npmrc.
  • Fixe versões exatas com save-exact=true.
  • Verifique proveniência com npm audit signatures.
  • Use Socket.dev (comportamental), Snyk (CVE) e npm audit (baseline) juntos.
  • Reduza dependências usando APIs nativas do Node.js e plataformas integradas como o Apidog.
  • Monitore saída de rede do CI/CD com StepSecurity Harden-Runner.

Cada dependência é uma decisão de confiança. Menos dependências = superfície de ataque menor. Quanto mais camadas de defesa, mais difícil para um invasor. Implemente verificações em profundidade.

Apidog

Top comments (0)