--- title: "Ataques à cadeia de suprimentos no npm e PyPI: como se proteger" description: "Como funcionam os ataques à cadeia de suprimentos de software, do typosquatting aos worms que se espalharam pelo npm em 2025, e as defesas que realmente…" url: "https://security.transitax.com/blog/ataques-cadeia-de-suprimentos-npm" --- Cadeia de suprimentos # Ataques à cadeia de suprimentos no npm e PyPI: como se proteger Como funcionam os ataques à cadeia de suprimentos de software, do typosquatting aos worms que se espalharam pelo npm em 2025, e as defesas que realmente funcionam. [Equipe de Pesquisa TransiTax Security](https://security.transitax.com/sobre#pesquisa)Publicado em 29 de julho de 2026Atualizado em 4 de agosto de 20265 min de leitura Resumo - Em setembro de 2025, pacotes npm com bilhões de downloads semanais foram comprometidos, e um worm se espalhou roubando tokens de mantenedores. - Pacotes maliciosos raramente recebem CVE, por isso o SCA tradicional não os detecta a tempo. - A máquina do desenvolvedor e o pipeline de CI são os alvos preferidos, porque guardam credenciais. - Defesas eficazes: lockfiles, atraso na adoção de versões novas, bloqueio de scripts de instalação, detecção comportamental de malware e proteção na máquina de desenvolvimento. Neste artigo 1. [Uma linha do tempo que mostra a escalada](#uma-linha-do-tempo-que-mostra-a-escalada) 2. [As técnicas mais comuns](#as-tecnicas-mais-comuns) 3. [Por que o SCA tradicional não basta](#por-que-o-sca-tradicional-nao-basta) 4. [Defesas que funcionam](#defesas-que-funcionam) 5. [O que fazer se você instalou uma versão maliciosa](#o-que-fazer-se-voce-instalou-uma-versao-maliciosa) 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](https://security.transitax.com/blog/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](#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](#as-tecnicas-mais-comuns) ### [Typosquatting](#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](#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](#confusao-de-dependencia) 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](#scripts-de-instalacao) 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](#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](#por-que-o-sca-tradicional-nao-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](https://security.transitax.com/funcionalidades/malware-em-dependencias) 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](#defesas-que-funcionam) ### [1\. Lockfiles sempre, e instalação reprodutível](#1-lockfiles-sempre-e-instalacao-reprodutivel) 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](#2-um-atraso-na-adocao-de-versoes-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](#3-scripts-de-instalacao-desativados-por-padrao) ```bash # 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](#4-escopos-e-registros-configurados-contra-confusao-de-dependencia) 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](#5-proteja-a-maquina-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](https://security.transitax.com/funcionalidades/protecao-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](#6-tokens-de-publicacao-com-escopo-minimo-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](#7-sbom-e-inventario-para-responder-rapido) Quando o próximo ataque acontecer, a pergunta será "estamos afetados?". Com um [SBOM](https://security.transitax.com/funcionalidades/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](#8-fixe-acoes-de-ci-por-hash) ```yaml # 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](#o-que-fazer-se-voce-instalou-uma-versao-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](https://security.transitax.com/blog/vazamento-de-secrets-no-git). 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. Quer ver isso rodando no seu código? Em 30 minutos mostramos a TransiTax Security num repositório seu, separando o que é explorável do que é ruído. [Falar com um especialista](https://security.transitax.com/contato) Escrito por Equipe de Pesquisa TransiTax Security Engenheiros de segurança de aplicações e de nuvem que acompanham registros de pacotes, bases de vulnerabilidades e técnicas de ataque. [Conheça a equipe](https://security.transitax.com/sobre#pesquisa). Neste artigo 1. [Uma linha do tempo que mostra a escalada](#uma-linha-do-tempo-que-mostra-a-escalada) 2. [As técnicas mais comuns](#as-tecnicas-mais-comuns) 3. [Por que o SCA tradicional não basta](#por-que-o-sca-tradicional-nao-basta) 4. [Defesas que funcionam](#defesas-que-funcionam) 5. [O que fazer se você instalou uma versão maliciosa](#o-que-fazer-se-voce-instalou-uma-versao-maliciosa) 6. [Perguntas frequentes](#perguntas-frequentes) ## Perguntas frequentes Respostas diretas às dúvidas mais comuns sobre o tema. ### O que é um ataque à cadeia de suprimentos de software? É quando o atacante compromete um componente em que você confia, como uma biblioteca de código aberto, uma ferramenta de build ou uma ação de CI, para que o código malicioso chegue até você por um canal legítimo. ### O SCA detecta pacotes maliciosos? O SCA tradicional, baseado em CVE, detecta mal, porque malware raramente recebe CVE e age em minutos. É preciso detecção comportamental dedicada, que analise cada nova versão publicada. ### O que é typosquatting? É a publicação de pacotes com nomes muito parecidos com os de pacotes populares, esperando que alguém digite errado no momento da instalação. ### Desativar scripts de instalação quebra meus projetos? Alguns pacotes com binários nativos precisam de scripts de build. A prática recomendada é bloquear por padrão e liberar explicitamente só os pacotes que precisam. ### Por que proteger a máquina do desenvolvedor? Porque ela guarda as credenciais mais valiosas: tokens de publicação, chaves de nuvem e acesso de escrita ao código. Os ataques mais recentes ao npm foram feitos justamente para roubar essas credenciais. ## Continue lendo - [SBOM na prática: CycloneDX, SPDX, VEX e o que seus clientes vão pedir3 de junho de 2026Cadeia de suprimentos](https://security.transitax.com/blog/sbom-guia-pratico) - [SAST, DAST, IAST e SCA: diferenças e quando usar cada um2 de setembro de 2026Fundamentos](https://security.transitax.com/blog/sast-dast-iast-sca-diferencas) - [SCA com alcançabilidade: por que a maioria dos alertas de CVE é ruído1 de julho de 2026Dependências](https://security.transitax.com/blog/sca-alcancabilidade) ## Veja o que é explorável no seu código Em 30 minutos mostramos a plataforma num repositório seu, separamos o risco real do ruído e montamos uma proposta em reais. [Falar com um especialista](https://security.transitax.com/contato) Resposta em até 1 dia útil.