A nova vulnerabilidade invisível do código gerado por IA

A inteligência artificial está a alterar o desenvolvimento de software ao reduzir o tempo necessário para escrever código, identificar erros e criar estruturas iniciais para novas aplicações. Esta aceleração, contudo, introduz uma dependência adicional num processo empresarial que já assenta em centenas de componentes externos. Quando as recomendações dos modelos não são verificadas, o ganho de produtividade pode ser acompanhado por uma perda de controlo sobre a origem do código incorporado nos sistemas.

Uma das limitações destas ferramentas é a capacidade de inventarem bibliotecas de software que parecem reais, mas que nunca foram publicadas. Os nomes sugeridos podem respeitar as convenções utilizadas pelos programadores, enquadrar-se tecnicamente no problema apresentado e surgir acompanhados por instruções de instalação plausíveis. A coerência da resposta não garante, porém, que o componente exista ou tenha uma origem legítima.

O risco surge quando uma recomendação inventada pela inteligência artificial deixa de ser tratada como uma hipótese e passa a integrar uma aplicação empresarial como uma dependência real.

Este mecanismo está na base do chamado slopsquatting. A técnica consiste no registo, por parte de um atacante, de um pacote com um nome previamente inventado por uma ferramenta de programação assistida por IA. Se um programador aceitar posteriormente a sugestão e instalar esse componente, poderá introduzir código malicioso num projeto legítimo sem reconhecer imediatamente a origem do problema.

A ameaça distingue-se de outras formas de fraude na distribuição de software. Nos ataques baseados em erros ortográficos, os criminosos tentam imitar o nome de uma biblioteca conhecida. No slopsquatting, o atacante não precisa de copiar um projeto existente. Basta ocupar uma designação fictícia que os modelos tenham tendência para recomendar.

Uma investigação recente, feita nos Estados Unidos, encontrou 127 nomes de pacotes inexistentes repetidos nas respostas de cinco modelos diferentes. O resultado sugere que estas alucinações não são totalmente aleatórias e que vários sistemas podem convergir para as mesmas designações, mesmo quando foram desenvolvidos por empresas distintas.

A repetição dos mesmos nomes reduz a imprevisibilidade das alucinações e permite que potenciais atacantes concentrem esforços num conjunto limitado de designações.

O estudo ainda não foi sujeito a revisão por pares, pelo que os seus resultados devem ser interpretados com prudência. Ainda assim, a questão identificada ultrapassa a precisão estatística da amostra. Se diferentes ferramentas recomendam regularmente os mesmos pacotes inexistentes, a falha deixa de ser apenas um erro ocasional do modelo e passa a representar um padrão potencialmente explorável.

Em abril, 53 dos 127 nomes identificados continuavam disponíveis para registo em dois dos repositórios públicos mais utilizados pelos ecossistemas de Python e JavaScript. Quarenta e um pertenciam ao primeiro destes ambientes e 12 ao segundo, mantendo aberta a possibilidade de uma terceira entidade ocupar as designações antes de um programador seguir uma recomendação incorreta.

A disponibilidade dos nomes não significa que esteja em curso uma campanha maliciosa. Os especialistas não encontraram indícios de que os pacotes ainda livres tivessem sido registados para distribuir malware ou utilizados num ataque. O dado relevante está, contudo, na existência de uma oportunidade técnica que pode ser explorada com um investimento reduzido.

Não foi identificada uma ofensiva associada aos nomes disponíveis, mas o processo necessário para transformar a falha num ataque já é conhecido e pode ser reproduzido.

A coincidência entre as respostas dos modelos pode ter origem nos dados utilizados durante o treino. Ferramentas diferentes podem ter absorvido as mesmas referências incorretas presentes em documentação pública, fóruns, tutoriais ou exemplos de código disponíveis na Internet. Uma informação errada suficientemente repetida pode, desta forma, ser reproduzida por vários sistemas como se correspondesse a uma dependência legítima.

Outra explicação reside na capacidade dos modelos para reconhecerem padrões linguísticos e técnicos. Mesmo sem terem encontrado uma determinada biblioteca durante o treino, conseguem construir um nome plausível a partir das convenções habituais de cada ecossistema. A designação poderá parecer coerente com a função pretendida, embora não exista qualquer projeto, equipa de manutenção ou histórico de versões por trás da recomendação.

Esta aparência de legitimidade é particularmente relevante nos ambientes empresariais. As equipas de desenvolvimento trabalham frequentemente com prazos curtos, múltiplas dependências e processos de integração contínua. Uma sugestão tecnicamente convincente pode ser aceite com menos escrutínio, sobretudo quando surge no interior de uma resposta que também contém código funcional.

O problema não está, portanto, apenas na capacidade da IA para inventar informação. Está também na forma como essa informação é apresentada e integrada nos fluxos de trabalho. Uma resposta fluida, detalhada e aparentemente segura pode transmitir um grau de confiança superior ao que a ferramenta realmente oferece.

Para os responsáveis de tecnologia, segurança e compras, esta limitação deve ser considerada na avaliação das plataformas de geração de código. A produtividade prometida por estas soluções não elimina a necessidade de verificar a existência, a origem, a manutenção e a reputação de cada componente sugerido.

A adoção empresarial de programação assistida por IA exige que todas as dependências sejam confirmadas antes de entrarem nos ambientes de desenvolvimento e produção.

Este controlo torna-se mais importante porque as aplicações modernas dependem de dezenas ou centenas de componentes externos. Uma única biblioteca comprometida pode afetar não apenas o código onde foi instalada, mas também os sistemas, os clientes e os parceiros que dependem dessa aplicação.

O slopsquatting demonstra como uma alucinação aparentemente inofensiva pode atravessar várias camadas da cadeia tecnológica. O processo começa numa resposta incorreta, passa pelo registo de um pacote e pode terminar na distribuição de código malicioso através de uma aplicação legítima.

Para as empresas, a questão central não é abandonar as ferramentas de geração de código, mas impedir que a velocidade substitua a validação. A inteligência artificial pode apoiar os programadores e reduzir tarefas repetitivas, mas não deve assumir o papel de fonte definitiva sobre a autenticidade dos componentes utilizados.

A segurança da cadeia de fornecimento de software dependerá, assim, da capacidade das organizações para integrarem a IA em processos controlados, nos quais cada recomendação seja tratada como uma proposta a confirmar e não como uma dependência automaticamente confiável.