A Entelgy Security América analisa como a IA pode transformar uma biblioteca inexistente em uma porta de entrada para invasores. O fenômeno do “slopsquatting” explora uma vulnerabilidade cada vez mais comum no desenvolvimento assistido por IA: pacotes que o modelo inventa, mas que um invasor pode registrar e utilizar para introduzir código malicioso em uma organização.
Um desenvolvedor pede ajuda ao assistente de IA. Recebe um trecho de código funcional que importa uma biblioteca com nome plausível. Ele roda o comando de instalação. Funciona. O código entra no repositório, passa pelo pipeline, chega em produção.
O detalhe é que essa biblioteca nunca existiu. O modelo a inventou. E alguém, sabendo que o modelo inventa esse nome com frequência, registrou o pacote no repositório público antes, com código malicioso dentro.
O ataque tem nome: slopsquatting, termo cunhado por Seth Larson, da Python Software Foundation. É primo do typosquatting, mas mais difícil de barrar: o nome não é erro de digitação, é inteiramente novo — não há heurística de similaridade que pegue.
O tamanho da superfície de ataque
Um estudo de pesquisadores da University of Texas at San Antonio, Virginia Tech e University of Oklahoma analisou 576 mil trechos de código gerados por 16 modelos em Python e JavaScript. 19,7% dos pacotes recomendados não existiam em nenhum repositório público — mais de 205 mil nomes fictícios distintos.
O número que interessa ao atacante é outro: 43% desses nomes alucinados se repetiram em todas as dez execuções do mesmo prompt. Alucinação, aqui, não é ruído aleatório: é comportamento previsível. Basta rodar prompts comuns, anotar os nomes que aparecem sempre, registrá-los e esperar
Modelos comerciais alucinam menos — cerca de 5%, contra mais de 20% em modelos abertos —, mas 5% de milhares de sugestões diárias ainda é volume relevante. E já há caso confirmado: o pacote malicioso unused-imports executava script de pós-instalação para roubar credenciais e chaves de API.
O tamanho da superfície de ataque
Dependência inventada é o vetor mais espetacular, mas não é o mais comum. O Future of Application Security Report 2026 da Checkmarx, conduzido pela Censuswide com 2.350 CISOs, gerentes de AppSec e desenvolvedores em 14 países, mede a distância entre consciência e prática:
- 96% dos desenvolvedores já têm ferramentas de IA dentro da IDE e quase todos as consideram eficazes, mas apenas 18% aplicam segurança de forma contínua enquanto escrevem o código.
- Organizações em que 81% a 100% do código de produção é gerado por IA têm quase três vezes mais chance de publicar software com vulnerabilidades conhecidas do que aquelas em que a IA gera de 1% a 20% (47% contra 14%).
- 75% das organizações admitem publicar código que já sabem ser vulnerável, pressionadas por prazo e complexidade. E 70% dos desenvolvedores acreditam que o código gerado por IA tem mais falhas, 30% o entregam mesmo assim.
Ou seja: a IA não introduziu um tipo novo de vulnerabilidade. Ela multiplicou a velocidade de produção de todos os tipos antigos, enquanto a capacidade de revisão continuou humana.
E a janela encolheu. Segundo a mesma pesquisa, o tempo médio até a exploração de uma vulnerabilidade caiu de cerca de 840 dias em 2018 para menos de dois dias em 2026. O backlog de correção deixou de ser problema de processo e virou problema de aritmética.
Sete controles, do mais barato ao mais estruturante
- Arquivo de lock obrigatório em todo projeto. package-lock.json, poetry.lock, go.sum. Sem ele, cada build é uma nova oportunidade de resolver uma dependência diferente da que foi revisada
- Verificação de existência e maturidade do pacote no pipeline. Pacote criado há seis dias, com um mantenedor e zero histórico merece bloqueio automático e revisão humana.
- Repositório interno como único caminho. Proxy corporativo com lista de pacotes aprovados. O desenvolvedor não instala direto do repositório público, instala do espelho curado.
- Bloqueio de scripts de pós-instalação por padrão. É onde o payload da maioria dos pacotes maliciosos executa.
- SCA e SBOM. SCA (Software Composition Analysis) identifica os componentes de terceiros e suas vulnerabilidades; SBOM (Software Bill of Materials, a lista de ingredientes do software) documenta o que existe dentro de cada entrega. Sem os dois, responder “esse pacote está em quais dos nossos sistemas?” leva uma semana.
- Revisão humana obrigatória para dependências novas. Especialmente as sugeridas por agentes de codificação, que instalam sem que ninguém leia o comando.
- Política escrita para desenvolvimento assistido por IA. O que pode ser gerado, o que precisa de revisão, o que nunca entra sem teste. Sem política, cada desenvolvedor cria a sua.
O que dizer ao board
A IA de código não deve ser proibida — o ganho de produtividade é real. O que precisa mudar é a proporção. Se 96% dos desenvolvedores já geram código com IA e apenas 18% verificam segurança enquanto escrevem, o gargalo não é consciência: é execução. Velocidade sem verificação não é produtividade — é dívida de segurança com prazo de exploração de dois dias.
