ia escolhendo bibliotecasslopsquattingpacote alucinado iacopilot dependências segurança

É seguro deixar a IA escolher as bibliotecas do seu sistema?

Pode ser, desde que a esteira confira o que a IA sugere. Assistentes de código às vezes indicam pacotes que não existem ou versões com falha conhecida, e criminosos já registram esses nomes inventados com código malicioso. Lockfile, verificação de vulnerabilidades no pull request e revisão humana de cada dependência nova fecham essa porta.

Por Equipe CyberArmor26 de março de 2026

Que risco entra quando a IA escolhe uma biblioteca?

Quase todo sistema moderno é montado com bibliotecas de terceiros, chamadas de dependências. Quando o programador pede ao ChatGPT, ao Copilot ou a outro assistente "como faço para ler este PDF" ou "atualize este projeto", a resposta costuma vir com um comando de instalação pronto. Ele copia, roda e segue o trabalho.

O problema é que o assistente escreve o nome do pacote e o número da versão com a mesma confiança com que escreve o resto do código. Se o nome estiver errado, ou se a versão tiver uma falha conhecida, o erro entra no seu produto e vai junto para o servidor do cliente. Para a empresa, a consequência é um sistema vulnerável que ninguém escolheu de propósito e que ninguém revisou.

Os riscos práticos são três:

Pacote inventado. A IA sugere uma biblioteca que não existe no repositório público (como PyPI e npm).
Versão vulnerável. A IA sugere uma versão antiga, que já tem falha publicada, porque foi treinada com exemplos antigos.
Atualização mal feita. A IA troca versões sem considerar o que quebra ou o que muda nas dependências indiretas.

O que é slopsquatting e por que ele preocupa?

Slopsquatting é o golpe de registrar, no repositório público, o nome de um pacote que a IA costuma inventar. Quem pede ajuda ao assistente recebe a sugestão, roda o comando de instalação e baixa o pacote do criminoso. O termo foi cunhado por Seth Larson, desenvolvedor de segurança da Python Software Foundation, segundo reportagem do The Register de abril de 2025.

O golpe funciona porque a invenção se repete. Um estudo acadêmico apresentado no USENIX Security Symposium de 2025 testou 16 modelos de geração de código em 576 mil amostras de Python e JavaScript. A média de pacotes inventados foi de pelo menos 5,2% nos modelos comerciais e de 21,7% nos modelos abertos, com 205.474 nomes inventados diferentes.

No mesmo estudo, os pesquisadores repetiram dez vezes cada pedido que tinha gerado um pacote inexistente. Segundo o artigo completo no arXiv, 43% dos nomes inventados voltaram nas dez tentativas. Ou seja, o criminoso consegue prever quais nomes a IA vai sugerir e registrá-los antes.

A OWASP, fundação que mantém guias abertos de segurança de software, trata o problema na sua lista de riscos de aplicações com modelos de linguagem. O item LLM09:2025 Misinformation descreve o modelo sugerindo bibliotecas inseguras ou inexistentes e o atacante publicando pacotes maliciosos com os nomes que os assistentes costumam inventar.

E quando a IA sugere uma versão com falha conhecida?

Esse risco é mais silencioso. O assistente aprendeu com código publicado ao longo de anos e tende a repetir versões que eram comuns na época. Uma versão antiga pode ter uma CVE (o identificador público de uma vulnerabilidade) já corrigida pelo fabricante.

O mesmo vale para pedidos de atualização. Se o programador pede "corrija esta vulnerabilidade" e aceita a primeira resposta, a IA pode trocar a versão errada, ignorar uma dependência indireta ou propor um contorno que abre outra falha. A orientação da OWASP no item LLM09 é conferir a saída do modelo com fontes confiáveis e validar automaticamente o que for crítico.

Que controles a equipe coloca na esteira?

A esteira é o caminho que o código percorre do computador do programador até o servidor. Os controles abaixo funcionam com ou sem IA, e são eles que pegam o erro que o assistente deixou passar.

Confirme que o pacote existe e é o certo. Antes de instalar algo novo, alguém abre a página do pacote no repositório oficial e confere nome, mantenedor, data de criação e histórico. Pacote criado há poucos dias, com nome parecido com outro famoso, merece desconfiança.
Trave as versões com lockfile. O lockfile é o arquivo que registra a versão exata de cada dependência, inclusive as indiretas. Com ele, a esteira instala sempre o mesmo conjunto que foi revisado.
Verifique vulnerabilidades em cada pull request. O pull request é o pedido de alteração que passa por revisão antes de entrar no código principal. No GitHub, a ação de revisão de dependências aponta versões vulneráveis introduzidas no pedido e pode bloquear a junção quando o repositório exige essa checagem. Fora do GitHub, o OSV-Scanner cruza as dependências do projeto com a base pública OSV.
Exija revisão humana para dependência nova. Uma regra simples resolve muito: nenhuma biblioteca nova entra sem que uma segunda pessoa aprove. A IA pode sugerir, mas quem assina é um programador.
Mantenha um inventário (SBOM). O SBOM é a lista de componentes do software. Quando sair uma falha nova, você descobre em minutos se está exposto.
Escreva uma política de uso de IA no código. Diga quais assistentes são permitidos, se eles podem instalar pacotes sozinhos e quem aprova mudanças de dependência.

Esses controles têm um limite. A verificação de dependências encontra vulnerabilidades já publicadas. Falha que ninguém descobriu ainda não aparece em nenhuma base, e por isso a revisão humana e o teste da aplicação continuam necessários.

Preciso proibir a IA na equipe de desenvolvimento?

Proibir costuma empurrar o uso para contas pessoais, onde a empresa perde a visibilidade. O caminho mais seguro é permitir com regras: assistente aprovado, nada instalado direto da sugestão, checagem automática no pull request e uma pessoa responsável por aprovar dependências.

Se os seus programadores também usam agentes que executam comandos sozinhos no computador, o risco aumenta, porque o agente pode instalar o pacote sem perguntar. Esse caso está em assistentes de código com acesso à máquina. Para o risco mais amplo de pacotes comprometidos, veja ataques à cadeia de suprimentos.

Por onde começar na sua empresa?

Comece descobrindo o que já entrou. Liste as dependências dos seus sistemas, rode uma verificação de vulnerabilidades e confira se há pacotes que ninguém sabe explicar por que estão lá.

Os analistas da CyberArmor fazem esse levantamento no Raio-X do código, um projeto de 2 a 3 semanas que mapeia dependências, falhas conhecidas e a configuração da sua esteira. Depois, a Esteira segura acompanhada mantém essas checagens funcionando a cada nova versão do seu software. Falar com um especialista.

Fontes