Slopsquatting ganhou espaço nas discussões de segurança ao mostrar como alucinações de modelos de linguagem podem transformar o primeiro dia de desenvolvimento em um ponto de invasão na cadeia de suprimentos de software.
O conceito mescla a ideia de “AI slop” com o antigo typosquatting, mas vai além dos erros de digitação. Aqui, o próprio assistente de código sugere bibliotecas que não existem. Quando um invasor registra o nome fantasma e publica um pacote contaminado, o malware é instalado sem levantar suspeitas. Essa mutação do risco, impulsionada por ferramentas de Inteligência Artificial, desloca as proteções tradicionais dos repositórios e aumenta a superfície de ataque.
Diferentemente do typosquatting — “crossenv” em vez de “cross-env”, por exemplo —, o slopsquatting baseia-se em nomes plausíveis, mas inéditos. Repositórios como npm ou PyPI não têm filtros para algo que, teoricamente, nunca existiu. Assim, políticas contra erros ortográficos deixam de ser eficientes quando a ameaça nasce da criatividade estatística de um LLM.
Pesquisadores já alertam para a persistência dessas alucinações. Um pacote falso pode passar meses em produção sem detecção, propagando código malicioso em inúmeras implantações. Em estudo que examinou 31.267 vulnerabilidades em 14.675 pacotes de dez linguagens, o número de falhas subiu 98% ao ano, ritmo bem superior ao crescimento (25%) do próprio ecossistema open source. Além disso, a vida útil média das vulnerabilidades aumentou 85%, indicando queda na eficácia das correções.
Outro trabalho avaliou 30 sistemas de geração de código e produziu 576 mil trechos que faziam referência a 2,23 milhões de dependências. Nada menos que 19,7% desses nomes eram invenções. O GPT-4 Turbo apresentou a menor taxa (3,59%), enquanto o DeepSeek 1B, um dos melhores modelos abertos, chegou a 13,63%. O resultado sugere que organizações que contam exclusivamente com ferramentas open source ficam expostas a um risco até quatro vezes maior de slopsquatting.
Como o slopsquatting explora alucinações de LLMs
Modelos de linguagem buscam a resposta estatisticamente mais provável, não a mais exata. Estima-se que a taxa de alucinação varie de 23% a 82%, a depender do modelo e do prompt. Ao gerar código, essa incerteza se traduz em dependências fictícias. Invasores, então, observam padrões, registram os nomes populares entre as alucinações e publicam versões contendo backdoors ou scripts de mineração de dados.
Boas práticas para conter o risco
- Automatizar a checagem de nomes contra registries oficiais antes do build.
- Monitorar logs de instalação em busca de dependências pouco conhecidas ou recém-criadas.
- Manter inteligência de ameaças atualizada sobre campanhas de slopsquatting divulgadas pela comunidade.
- Realizar análises de conteúdo dos pacotes, procurando padrões de ofuscação ou chamadas externas suspeitas.
- Treinar equipes para revisar manualmente sugestões de IA, garantindo que bibliotecas existam e tenham histórico confiável.
A tendência de “vibe coding” — quando mais de 40% do código já nasce com ajuda de IA, segundo pesquisa do setor — expande ainda mais a exposição. Setenta e dois por cento dos desenvolvedores que experimentaram assistentes inteligentes afirmam usá-los diariamente. Sem validação automática, cada nova dependência recomendada pode ser uma porta aberta.
Embora modelos proprietários apresentem índice menor de alucinações, especialistas lembram que essa vantagem pode diminuir conforme criminosos se concentrem em manipular essas plataformas. A melhor prática, portanto, é assumir que qualquer sugestão pode ser falha e incorporar verificações contínuas no pipeline de CI/CD.
O alerta não significa abandonar ferramentas de IA, mas sim amadurecer o uso. Ao revisitar políticas de segurança, empresas devem tratar slopsquatting como um vetor legítimo de risco em auditorias, mantendo inventário rigoroso de dependências e atualizando processos de due diligence para um cenário em que a imaginação dos modelos é explorada como arma.
Para conhecer detalhes técnicos do estudo que mediu o crescimento de falhas em bibliotecas open source, acesse a publicação no arXiv.
Comentários
Participe com respeito. Comentários passam por proteção anti-spam simples.