O que é um ataque de supply chain e como reduzir os riscos de segurança
Entenda o que é um ataque de supply chain, como ele se espalha e como reduzir o risco.
6 min de leitura
- segurança
- kastavo
Quando você instala uma dependência para um projeto, confia em uma cadeia inteira de código que nunca escreveu. Um ataque de supply chain (cadeia de suprimentos) explora exatamente essa confiança: em vez de atacar o seu site diretamente, o invasor compromete uma biblioteca que milhares de outros projetos já usam e espera você instalar a versão infectada.
O caso que mostra o tamanho do problema
Em uma campanha que atingiu o axios, uma biblioteca JavaScript muito usada para fazer requisições HTTP, alguém assumiu o controle da conta do mantenedor principal no npm e publicou duas versões maliciosas, com cerca de 39 minutos de diferença, como se fossem lançamentos normais do projeto. As versões ficaram no ar por algumas horas, até o npm removê-las.
Não foi um caso isolado. A ReversingLabs, empresa de segurança de software, registrou uma alta de cerca de 73% nas detecções de pacotes maliciosos de código aberto em 2025 em relação a 2024, com mais de 10 mil identificados só no npm. E em uma campanha recente chamada Shai-Hulud, mais de cem pacotes npm foram comprometidos por um código que se replicava sozinho.
Como o ataque se espalha
O mecanismo costuma seguir um padrão simples:
- O invasor rouba credenciais de um mantenedor (phishing, engenharia social ou vazamento de token em outro serviço comprometido)
- Usa essas credenciais para publicar uma versão nova do pacote, com código malicioso escondido
- Quem instala ou atualiza a dependência recebe o código infectado junto, sem perceber, porque o pacote continua vindo da fonte "oficial"
- Em alguns casos, o malware é capaz de se replicar sozinho: ele usa os tokens roubados para encontrar outros pacotes do mesmo mantenedor e infectar aqueles também, criando um efeito em cadeia
O perigo central é esse: do ponto de vista de quem instala, parece uma atualização normal. Não tem aviso, não tem alerta: é só mais uma versão de uma biblioteca que você já usava.
Se seu site tem backend: o que dá para fazer
Para quem roda aplicações com servidor (a maioria dos sites), não existe solução mágica, mas há práticas que reduzem bastante o risco:
- Travar versões de dependências (lockfiles, como o package-lock.json) em vez de sempre puxar a versão mais recente automaticamente
- Auditar dependências regularmente com ferramentas como npm audit, Socket Security ou Snyk, que monitoram pacotes conhecidos por comportamento suspeito
- Revisar o que uma atualização realmente muda antes de aplicar em produção, especialmente em bibliotecas com muito acesso (autenticação, manipulação de arquivo, requisições de rede)
- Usar publicação confiável (trusted publishing) quando disponível: um mecanismo mais recente que elimina a necessidade de tokens de longa duração, reduzindo o que pode ser roubado
- Limitar o que o backend pode acessar, pelo princípio de menor privilégio: se uma dependência comprometida só tem acesso ao que é estritamente necessário, o estrago potencial é menor
Nenhuma dessas práticas é garantia total. Um ataque de supply chain é, por natureza, difícil de prevenir por completo, porque explora a própria confiança que torna o ecossistema de pacotes útil.
Se seu site não tem backend processando arquivos
Esse é o caso do Kastavo. Como as ferramentas rodam inteiramente no navegador, não existe um servidor recebendo o arquivo da pessoa e processando com dependências de backend. Por isso, um vetor específico de ataque simplesmente não existe aqui: não há como uma dependência comprometida no lado do servidor acessar arquivos que nunca chegaram a esse servidor, porque eles nunca saem do dispositivo de quem está usando a ferramenta.
Isso reduz a exposição, mas não elimina todo risco. Uma arquitetura client-side ainda depende de:
- Dependências usadas durante o desenvolvimento e o build: se uma biblioteca usada para montar o site for comprometida, o código que chega ao navegador da pessoa pode ser afetado
- Scripts de terceiros carregados na página: qualquer script externo (analytics, anúncios, fontes) é, em si, uma dependência de confiança
- A integridade do próprio pipeline de publicação: do commit até o deploy, cada etapa é um elo que precisa estar protegido
Por isso, mesmo sem backend processando arquivo, ainda vale aplicar as mesmas práticas da seção anterior (lockfiles, auditoria, princípio de menor privilégio) no ambiente de desenvolvimento e de build.
O que fica de lição
Um ataque de supply chain não é um problema que se resolve com uma ferramenta ou configuração única: é uma categoria de risco que cresce junto com a quantidade de dependências que qualquer projeto moderno acumula. A arquitetura de onde o processamento acontece (servidor ou navegador) muda quais vetores existem, mas não substitui as práticas básicas de segurança em nenhum dos dois casos.
A pergunta mais útil, na hora de escolher que ferramenta usar para um arquivo sensível, não é só "ela é segura?", mas "a que exatamente ela está exposta, e por quê?"
Perguntas frequentes
É um ataque que, em vez de invadir o seu site ou aplicativo diretamente, compromete algo em que você já confia: uma biblioteca, uma ferramenta de build ou a conta de quem mantém um pacote. Como a versão infectada chega pelo canal normal de atualização, quem instala costuma não perceber.
Não. Rodar tudo no navegador elimina o vetor em que uma dependência de servidor acessa os arquivos enviados, porque eles nunca chegam a um servidor. Mas o site ainda depende de bibliotecas usadas no desenvolvimento e no build, de scripts de terceiros carregados na página e da segurança do processo de publicação. O risco diminui, mas não desaparece.
Não há garantia total, mas ajuda bastante travar as versões com um lockfile, auditar as dependências com ferramentas como npm audit, Socket Security ou Snyk, revisar o que cada atualização muda antes de ir para produção, usar publicação confiável (trusted publishing) quando disponível e limitar o que o backend pode acessar.
