Ataques à cadeia de suprimentos no npm e PyPI: como se proteger

Um ataque à cadeia de suprimentos de software acontece quando o atacante não invade você diretamente: ele compromete algo em que você confia, como uma biblioteca, uma ferramenta de build ou uma ação de CI, e deixa que você mesmo instale o código malicioso. O OWASP Top 10 2025 deu a esse risco uma categoria própria, a A03, e os eventos dos últimos anos explicam por quê.

Uma linha do tempo que mostra a escalada

• 2018, event stream: um mantenedor passou o controle de um pacote popular a um desconhecido, que adicionou código para roubar carteiras de criptomoeda.
• 2021, ua parser js: a conta do mantenedor foi sequestrada e versões com minerador e ladrão de senhas foram publicadas.
• 2021, confusão de dependência: um pesquisador demonstrou que publicar pacotes públicos com os nomes de pacotes internos de grandes empresas fazia seus sistemas de build baixarem a versão pública.
• 2024, xz utils: uma porta dos fundos foi inserida numa biblioteca de compressão presente em quase toda distribuição Linux, depois de anos de construção de confiança por um colaborador falso. Foi descoberta por acaso, por causa de um atraso de meio segundo no SSH (CVE 2024 3094).
• Setembro de 2025, npm: um mantenedor de pacotes utilitários extremamente populares caiu num email de phishing que imitava o suporte do npm. Versões maliciosas de dezenas de pacotes, somando bilhões de downloads semanais, foram publicadas com código que desviava transações de criptomoeda no navegador.
• Setembro de 2025, worm no npm: dias depois, um malware autorreplicante passou a roubar tokens do npm e credenciais de nuvem das máquinas que o instalavam, e usava esses tokens para publicar versões infectadas de outros pacotes dos mesmos mantenedores. Centenas de pacotes foram afetados, e uma segunda onda apareceu em novembro.

O padrão é claro: os ataques ficaram mais rápidos, mais automatizados e mais focados em roubar credenciais de quem desenvolve.

As técnicas mais comuns

Typosquatting

Pacotes com nomes parecidos com os populares, esperando um erro de digitação: reqeusts no lugar de requests, colours no lugar de colors. Registros públicos removem milhares desses pacotes por ano, mas novos aparecem todo dia.

Sequestro de conta do mantenedor

Phishing, reutilização de senhas ou tokens vazados dão ao atacante o direito de publicar novas versões de um pacote legítimo. É o ataque mais perigoso, porque a atualização parece normal.

Confusão de dependência

Se a sua empresa usa um pacote interno chamado @empresa/utils e o gerenciador de pacotes consulta também o registro público, um atacante publica um pacote com o mesmo nome e versão maior. O build escolhe a versão pública.

Scripts de instalação

No npm, preinstall e postinstall executam código arbitrário no momento do npm install, antes de qualquer revisão. No Python, o setup.py tem o mesmo efeito. É por aí que a maioria do malware se ativa.

Comprometimento do pipeline

Ações de CI de terceiros, imagens base e ferramentas de build também são dependências. Uma ação comprometida no pipeline tem acesso aos secrets do repositório.

Por que o SCA tradicional não basta

A análise de composição de software (SCA) clássica compara as versões das suas dependências com bases de vulnerabilidades conhecidas (CVE). Malware não funciona assim:

• Pacotes maliciosos raramente recebem CVE. São removidos do registro e ganham, no máximo, um aviso.
• O tempo entre a publicação e o dano é de minutos a horas. Bases públicas levam dias.
• O código malicioso costuma estar ofuscado e só se ativa em certas condições.

É preciso uma camada que analise comportamento: o que o pacote faz ao ser instalado, que conexões abre, que arquivos lê. A detecção de malware em dependências da TransiTax Security analisa cada nova versão publicada nos principais registros e executa a instalação em sandbox, com mediana de 4 minutos entre a publicação e a regra ativa.

Defesas que funcionam

1. Lockfiles sempre, e instalação reprodutível

Faça commit de package-lock.json, pnpm-lock.yaml, poetry.lock e equivalentes. No CI, use npm ci ou pnpm install --frozen-lockfile, que nunca atualizam versões por conta própria.

2. Um atraso na adoção de versões novas

A maior parte das versões maliciosas é removida em poucas horas ou dias. Configurar ferramentas de atualização para só propor versões publicadas há pelo menos alguns dias elimina uma fatia grande do risco a custo quase zero.

3. Scripts de instalação desativados por padrão

# npm: não executar scripts de ciclo de vida
npm config set ignore-scripts true

# pnpm: só pacotes aprovados podem rodar scripts de build (pnpm 10 em diante)
# no package.json: "pnpm": { "onlyBuiltDependencies": ["esbuild", "sharp"] }

4. Escopos e registros configurados contra confusão de dependência

Use escopos para pacotes internos e configure o gerenciador para buscar esse escopo apenas no registro privado. Registre também o seu escopo no registro público, para que ninguém o ocupe.

5. Proteja a máquina de quem desenvolve

A máquina do desenvolvedor tem tokens de nuvem, chaves SSH e acesso de escrita ao código. Os worms de 2025 foram construídos para roubar exatamente isso. A proteção de dispositivos bloqueia a instalação de pacotes maliciosos antes que o script rode.

6. Tokens de publicação com escopo mínimo e MFA

Para quem publica pacotes: MFA obrigatório, tokens granulares com prazo curto e, onde possível, publicação confiável via OIDC a partir do CI, sem token estático.

7. SBOM e inventário para responder rápido

Quando o próximo ataque acontecer, a pergunta será "estamos afetados?". Com um SBOM atualizado de cada serviço e uma plataforma que cruza isso com alertas de malware, a resposta leva segundos. Sem isso, leva dias de grep em repositórios.

8. Fixe ações de CI por hash

# Em vez de uma tag que pode ser movida
- uses: acao/exemplo@v4
# Fixe no commit exato
- uses: acao/exemplo@3f1c2a9e8b7d6c5f4e3d2c1b0a9f8e7d6c5b4a3f

O que fazer se você instalou uma versão maliciosa

1. Identifique todas as máquinas e pipelines que instalaram a versão (SBOM e logs de CI).
2. Considere comprometidas todas as credenciais acessíveis nessas máquinas: tokens do npm e do GitHub, chaves de nuvem, variáveis de ambiente do CI.
3. Rotacione essas credenciais seguindo o roteiro de secret vazado.
4. Remova a versão, fixe uma versão segura e limpe caches.
5. Procure persistência: novos tokens, novas chaves SSH autorizadas, workflows de CI alterados.