O risco de terceiros saiu das “velhas” dependências de código aberto e chegou aos assistentes de código com IA: a cadeia de suprimentos hoje vai de SolarWinds e Log4Shell até o slopsquatting em PyPI e npm.Esse modelo de desenvolvimento orientado à velocidade: do “move fast and break things” ao “vibe coding” acelera a inovação, mas também distribui vulnerabilidades na escala industrial, criando uma superfície de ataque que agentes de ameaça já aprenderam a explorar.
Da SolarWinds e Log4J à crise da cadeia de abastecimento
A violação da SolarWinds, em 2020, mostrou o poder destrutivo de um fornecedor upstream comprometido: uma atualização envenenada incluída um backdoor para cerca de 18 mil clientes, incluindo várias agências federais dos EUA. Logo depois, o bug Log4Shell em Log4J expôs centenas de milhões de aplicações e dispositivos, com organizações lutando por semanas apenas para descobrir onde a biblioteca estava embutida em seus produtos e nos de terceiros.
Esses casos deixaram claro que bibliotecas de código aberto amplamente utilizadas podem se tornar pontos únicos de falha, especialmente em ambientes OT com sistemas legados difíceis de corrigir.
A mensagem foi duradoura: não basta proteger o perímetro próprio se a cadeia de fornecedores está cheia de componentes pouco governados, sem inventário nem visibilidade.
Vibe coding e o surgimento do slopsquatting
UM geração de código com IA virou o novo “killer app”: pesquisas indicam que a esmagadora maioria dos desenvolvedores já usou ferramentas de IA para programar no último ano. Mas esses assistentes também “alucinam” dependências — sugerem pacotes que não existem — e estudos acadêmicos mostram que cerca de 19% dos pacotes recomendados por 16 principais ferramentas de código não existem, com quase metade dessas alucinações repetidas sistematicamente.
Criminosos conseguiram a registrador pacotes maliciosos com os mesmos nomes sugeridos pelos modelos, num ataque batizado de slopsquatting por analogia a typosquatting. Um exemplo real é o pacote Python “ccxt-mexc-futures”, publicado no PyPI, que se apresentou como extensão legítima de uma popular biblioteca de negociação, mas na prática alterou funções críticas para desviar ordens na exchange MEXC e roubar tokens.
Do worm Shai‑Hulud ao risco de worms “IA‑assistidos”
Ataques como o worm Shai‑Hulud em npm mostram o próximo estágio do problema: código malicioso auto‑replicante que se injeta em centenas de pacotes e repositórios a partir de um único ponto de infecção.
Além de roubar tokens .npmrc, PATs do GitHub e chaves de nuvem, esse tipo de malware explora o fato de que pipelines CI/CD tendem a confiar cegamente em dependências “populares”.
Pesquisas já sugerem que partes de scripts maliciosas de campanhas recentes foram escritas ou “melhoradas” por LLMs, inclusive com comentários e até emojis, o que reduz o custo de desenvolvimento de ataques complexos.Se slopsquatting e worms da cadeia de suprimentos convergirem, basta um pacote alucinado amplamente adotado para disparar um worm massivo antes mesmo de ser detectado.
Visibilidade, SBOM e “shift left” real
SolarWinds tratou de supervisão da cadeia; Log4J de observabilidade sobre dependências; slopsquatting expõe a necessidade de supervisão dos próprios assistentes de código. O que é comum é visibilidade: sem inventário de ativos e dependências, não há como avaliar impacto nem responder rápido quando um pacote, fornecedor ou componente é comprometido.
Para isso, as organizações precisam de SBOMs atualizados para rastrear a origem e a versão de cada biblioteca, combinadas com SAST/DAST e análise de composição de software (SCA) nos pipelines para capturar vulnerabilidades e pacotes suspeitos antes da implantação. Equipes de segurança também devem monitorar IOAs: conexões inesperadas, comportamento anômalo de processos, novos domínios de atualização/configuração, onde a IA pode ajudar a detectar desvios sutis em ambientes complexos.
Tornando assistentes de código parte segura do tempo
Assistentes de código com IA precisam ser tratados como “dev júnior superprodutivo”: tudo que produzidas deve passar por revisão humana obrigatória, testes e validação de segurança. Os desenvolvedores devem incorporar segurança nos próprios prompts (validar entrada, evitar gerenciamento manual de autenticação, não expor segredos) e nunca aceitar cegamente pacotes recomendados sem verificar existência, confirmação e código-fonte.
No nível de processo, é fundamental “mudar para a esquerda” de verdade: envolve segurança desde a concepção, exige aprovação para novas dependências, e usa políticas de lista de permissões/restrições de registros em CI/CD para impedir que pacotes recém-criados e não revisados entrem em produção. Somado ao monitoramento contínuo e resposta a incidentes maduros, esse modelo ajuda a reduzir o risco de que uma próxima “alucinação” da IA se torne o ponto de partida de um ataque à cadeia de suprimentos de alto impacto.
