O risco de terceiros saiu das “velhas” dependências open source 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 em escala industrial, criando uma superfície de ataque que agentes de ameaça já aprenderam a explorar.
De SolarWinds e Log4J à crise de supply chain
A violação da SolarWinds, em 2020, mostrou o poder destrutivo de um fornecedor upstream comprometido: uma atualização envenenada espalhou um backdoor para cerca de 18 mil clientes, incluindo múltiplas 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 open source amplamente usadas podem se tornar pontos únicos de falha, especialmente em ambientes OT com sistemas legados difíceis de corrigir.
A mensagem foi dura: 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
A 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 começaram a registrar 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 apresentava como extensão legítima de uma popular biblioteca de trading, mas na prática alterava 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 maliciosos 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 de supply chain 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 integridade da cadeia; Log4J de observabilidade sobre dependências; slopsquatting expõe a necessidade de supervisão dos próprios assistentes de código. O elo 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, organizações precisam de SBOMs atualizadas para rastrear origem e versão de cada biblioteca, combinadas com SAST/DAST e análise de composição de software (SCA) nos pipelines para pegar vulnerabilidades e pacotes suspeitos antes do deploy. 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 time
Assistentes de código com IA precisam ser tratados como “dev júnior superprodutivo”: tudo que produzem deve passar por revisão humana obrigatória, testes e validação de segurança. 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, reputação e código-fonte.
No nível de processo, é fundamental “mudar para a esquerda” de verdade: envolver segurança desde a concepção, exigir aprovação para novas dependências, e usar políticas de allowlist/restrições de registries em CI/CD para impedir que pacotes recém‑criados e não revisados entrem em produção. Somado a monitoramento contínuo e resposta a incidentes madura, esse modelo ajuda a reduzir o risco de que a próxima “alucinação” da IA se torne o ponto de partida de um ataque de supply chain de alto impacto.
