O código da IA parece seguro. E o pacote que ela mandou instalar?
Você pede a um copiloto que implemente uma integração. Ele devolve uma função que parece correta, alguns testes e uma linha adicional:
npm install alguma-biblioteca
Ou:
pip install algum-pacote
Você revisa o código, confere a assinatura das funções, olha os testes e executa a aplicação. Tudo funciona.
Só que uma pergunta ficou fora do code review: quem revisou o pacote?
E não estou falando apenas de consultar uma base de vulnerabilidades conhecidas. Antes disso, há perguntas mais básicas:
- Há quanto tempo esse pacote existe?
- Quem o mantém?
- O repositório indicado pelo registry é mesmo o projeto oficial?
- Essa dependência era necessária?
- Ela executa algum script durante a instalação?
- A versão sugerida é confiável?
Há ainda uma pergunta que praticamente não existia antes dos coding assistants:
Esse pacote já existia antes de a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → sugeri-lo?
A supply chain já era um problema antes da IA
Software moderno é construído sobre software de outras pessoas. Mesmo uma aplicação relativamente pequena pode depender diretamente de algumas dezenas de bibliotecas e, de forma indireta, de centenas ou milhares de componentes.
Cada dependência amplia a cadeia de confiança. Você confia no pacote e nos pacotes dos quais ele depende. Confia também nos mantenedores, nas contas usadas para publicar releases, no registry, no pipeline de build e no processo que produziu aquela versão.
Nada disso começou com a IA.
Em setembro de 2025, por exemplo, credenciais de um mantenedor do ecossistema npm foram comprometidas. Versões maliciosas de pacotes amplamente utilizados, entre eles chalk e debug chegaram ao registry. Segundo o GitHub, os pacotes afetados somavam mais de dois bilhões de downloads semanais, e as versões comprometidas ficaram disponíveis por aproximadamente duas horas.
Duas horas podem parecer pouco para uma pessoa. Para uma automação que procura a versão mais recente assim que ela é publicada, é tempo suficiente.
O episódio não foi provocado por IA. Ele lembra que um nome conhecido no registry não prova que a versão disponível naquele momento é segura.
O que a IA mudou
Durante muito tempo, adicionar uma dependência exigia uma decisão relativamente explícita. Alguém pesquisava uma biblioteca, comparava alternativas, lia a documentação e, depois, executava o comando de instalação.
É claro que esse processo nem sempre era cuidadoso. Ainda assim, havia um momento perceptível de escolha.
Os coding assistants encurtaram esse intervalo. O mesmo sistema que escreve a implementação pode sugerir a biblioteca, gerar o comando de instalação, modificar o package.json ou o requirements.txt. Atualizar o lockfile e adaptar o código para usar a nova dependência.
Com agentes mais autônomos, tudo isso pode acontecer dentro de uma única tarefa.
A decisão, antes apresentada como “qual biblioteca devemos adotar?”, agora aparece diluída em um diff muito maior. E é fácil revisar a função sem perceber que a mudança mais importante do pull request talvez esteja em uma única linha do arquivo de dependências.
Quando o pacote nem existe
Código gerado por IA tem uma classe especialmente curiosa de erro: a package hallucination.
O modelo sugere uma biblioteca com um nome perfeitamente plausível. O nome segue a convenção do ecossistema e parece descrever exatamente a solução procurada. Há apenas um problema: o pacote não existe.
Um estudo apresentado no USENIX Security 2025 avaliou 16 modelos de geração de código e produziu 576 mil amostras em Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → e JavaScript. Os pesquisadores encontraram uma taxa média de pacotes alucinados de pelo menos 5,2% entre modelos comerciais e 21,7% entre modelos open source. No total, identificaram mais de 205 mil nomes únicos de pacotes inventados.
À primeira vista, isso parece apenas inconveniente. Você tenta instalar, o registry informa que o pacote não existe e você procura outra solução.
Mas alguém pode transformar essa alucinação em um ataque.
Slopsquatting: quando alguém registra o pacote que a IA inventou
Imagine que um modelo sugira repetidamente um pacote chamado:
fastapi-auth-helper
O nome não existe no PyPI. Um atacante percebe que os modelos costumam sugeri-lo e registra o pacote.
A partir desse momento, ele passa a existir. Na próxima vez que um desenvolvedor receber a mesma recomendação e executar:
pip install fastapi-auth-helper
A instalação funcionará. A diferença é que o código foi publicado pelo atacante.
Esse padrão passou a ser chamado de slopsquatting.
A distinção em relação ao typosquatting importa. No typosquatting, o atacante espera que uma pessoa digite incorretamente o nome de uma dependência legítima. No slopsquatting, ele explora um nome plausível inventado pelo modelo.
Nesse caso, o erro chega acompanhado da credibilidade da interface que fez a recomendação. Para quem recebe a resposta, não parece um erro de digitação. Parece uma solução.
O problema maior é que o pacote pode existir
Seria confortável encerrar a discussão com uma regra simples:
Antes de instalar, confirme se o pacote existe.
A regra evita parte do problema, mas está longe de resolver a segurança da supply chain.
Um pacote pode existir e ainda assim ser a escolha errada. Pode estar abandonado, ter poucos mantenedores ou ter sido criado há poucos dias. Pode adicionar dezenas de dependências transitivas para resolver algo que exigiria cinco linhas de código. Também pode executar scripts durante a instalação, apontar para um repositório diferente do esperado ou ter vulnerabilidades conhecidas.
Há ainda outra possibilidade: o pacote é legítimo, mas a conta usada para publicá-lo acabou de ser comprometida.
É nesse ponto que a conversa deixa de ser apenas sobre dependências inventadas por IA e volta a ser uma discussão de engenharia. A IA cria uma nova origem para a decisão, mas não muda o tipo de confiança que uma dependência exige.
Entre a sugestão e a execução quase não há mais distância
O risco aumenta quando o coding assistant deixa de apenas sugerir e passa a operar ferramentas.
Um chat que responde:
Use a biblioteca X.
Cria um tipo de risco. Um agente autorizado a executar:
npm install X
cria outro. A diferença está no tempo disponível e na oportunidade de revisão.
Quanto mais autonomia o agente recebe, mais importantes se tornam as verificações automáticas antes da instalação, do commit e do merge.
Essa preocupação já aparece nas próprias ferramentas de desenvolvimento. Em 2026, o GitHub passou a aplicar validações automáticas também ao código produzido por coding agents de terceiros, incluindo CodeQL para vulnerabilidades, secret scanning e verificação de novas dependências no GitHub Advisory Database.
O GitHub MCP Server também passou a permitir que agentes consultem vulnerabilidades em dependências antes do commit.
A direção é coerente: se automatizamos a criação, precisamos automatizar parte da desconfiança.
Dependência sugerida por IA precisa passar por um gate
Eu trataria qualquer dependência nova sugerida por IA como uma proposta, nunca como uma decisão pronta. Antes de aceitar um pacote, algumas perguntas deveriam ser obrigatórias.
1. O pacote existe e é o projeto que pensamos que é?
Abra o registry. Confira o repositório oficial, os mantenedores e o histórico. Um nome convincente em uma resposta não é evidência suficiente.
2. Precisamos mesmo dessa dependência?
A IA tende a resolver problemas recombinando padrões presentes em seus dados. Às vezes, isso significa importar uma biblioteca mesmo quando o projeto já possui outra dependência capaz de executar a mesma tarefa. Em outros casos, nenhuma biblioteca adicional seria necessária.
Cada pacote que não entra no projeto é uma superfície de supply chain a menos para administrar.
3. Qual versão está entrando?
“Última versão” não significa “versão mais segura”. Ataques de supply chain se aproveitam justamente da velocidade das automações.
Em 2026, o Dependabot passou a aplicar um período de espera padrão de três dias para atualizações de versão. A medida dá tempo para que sinais de comprometimento apareçam antes que releases recém-publicadas sejam distribuídas automaticamente.
4. O que acontece durante a instalação?
Scripts de preinstall, install e postinstall merecem atenção especial. O tema ganhou tanto peso que o npm anunciou, para a versão 12, a desativação dos scripts de instalação por padrão. Os casos que dependem deles precisarão de aprovação explícita.
5. Existem vulnerabilidades ou alertas de malware?
A verificação das dependências deve acontecer antes do merge, não depois do incidente.
Em 2026, o GitHub ampliou os alertas de pacotes maliciosos do Dependabot para vários ecossistemas. A cobertura usa dados compartilhados pelo OpenSSF para npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io e Composer.
6. Conseguimos provar de onde veio o artefato?
Proveniência, releases assinados, trusted publishing, lockfiles e frameworks como SLSA não tornam a supply chain perfeita. Eles reduzem a quantidade de confiança implícita, o que é justamente o que precisamos fazer.
O que eu exigiria de um time que usa coding agents
Se coding agents podem alterar dependências, eu colocaria algumas regras no projeto:
- Toda dependência nova deve aparecer explicitamente no resumo do pull request;
- Agentes não devem instalar silenciosamente pacotes desconhecidos;
- Dependências novas precisam passar por verificação de vulnerabilidades e malware;
- Pacotes muito recentes ou sem histórico devem receber uma revisão adicional;
- Lockfiles fazem parte do code review;
- As versões devem ser fixadas de acordo com a política do projeto;
- Scripts executados durante a instalação precisam estar visíveis;
- Ambientes mais críticos podem adotar uma allowlist de componentes aprovados;
- O SBOM e o inventário de componentes devem refletir o que realmente foi entregue;
- A pessoa que aprova o PR continua responsável por entender por que aquela dependência está entrando.
A orientação da OWASP para desenvolvimento seguro com IA resume bem a postura: verifique os pacotes sugeridos antes da instalação e não presuma que uma dependência é real ou segura só porque o assistente a recomendou.
É uma regra simples. Talvez por isso seja tão útil.
O novo code review olha além do código
Nos últimos anos, aprendemos que revisar um pull request envolve mais do que verificar se uma função está correta. Também precisamos olhar para permissões, infraestrutura, secrets, pipelines, dependências e comportamento operacional.
Com a IA, essa fronteira ficou ainda mais nítida. O copiloto pode escrever vinte linhas excelentes e acrescentar uma única dependência capaz de mudar por completo o perfil de risco da aplicação.
Supply chain é, no fim das contas, uma discussão sobre confiança. A IA acelera algumas decisões, mas não torna essa confiança mais barata. Quanto menor a distância entre “sugira uma solução” e “instale o que for necessário”, mais explícitos precisam ser os controles.
O pacote pode estar no npm ou no PyPI. Pode ter milhares de downloads. Pode ter sido sugerido pelo melhor coding assistant disponível. Nada disso substitui a pergunta que deveria surgir antes do install:
Por que estamos confiando neste código?
O copiloto pode sugerir a dependência. Quem aprova a entrada dela na supply chain ainda assina embaixo.
John Calistro é mentor de empregabilidade em tecnologia e autor de conteúdos práticos sobre portfólio que contrata, IA para estudar e revisar código, entrevistas e posicionamento no LinkedIn. Ajuda iniciantes e migrantes a sair da estagnação e conquistar o 1º emprego com projetos que mostram impacto real.
