O código gerado por IA é seguro? Os riscos de segurança explicados

Os assistentes de programação com IA se tornaram silenciosamente os desenvolvedores mais rápidos da sua equipe. Eles autocompletam funções, montam serviços inteiros e respondem "como faço X" dentro do editor sem troca de contexto. Os ganhos de produtividade são reais e não vão desaparecer. Mas a velocidade é só metade da história. A verdade incômoda é que muito do código gerado por IA entra em produção inseguro — e entender os riscos de segurança do código gerado por IA agora é parte central de fazer AppSec bem-feito.

Este não é um problema de hype nem hipotético. Vários estudos constataram que uma parcela substancial — frequentemente citada na faixa de 40–50% — das amostras de código gerado por IA contém pelo menos uma falha de segurança. Que o número real seja um pouco maior ou menor na sua base de código quase não importa. O ponto é que "a máquina escreveu" não é uma garantia de segurança, e tratar o código gerado como confiável por padrão é como as vulnerabilidades escapam para a produção em uma escala para a qual a revisão manual nunca foi projetada.

Então vamos responder à pergunta com franqueza. O código gerado por IA é seguro? Às vezes. Com bastante frequência, não é. E a diferença entre os dois se resume a você ter ou não uma camada de segurança que o inspeciona antes de ele entrar em produção. Abaixo estão as categorias de risco que mais importam, cada uma com um exemplo concreto e a classe de ferramenta que a detecta.

Padrões inseguros por padrão

A categoria mais comum de vulnerabilidades do código gerado por IA também é a mais banal: código que funciona, passa em uma inspeção rápida e omite silenciosamente um controle de segurança. Os modelos de linguagem são treinados para produzir código plausível e funcional. Eles não são treinados para produzir código seguro, e "funcional" e "seguro" não são a mesma coisa.

Peça a um assistente um endpoint de busca e você pode receber uma consulta SQL construída com concatenação de strings — uma falha de injeção clássica — porque esse padrão aparece o tempo todo nos dados de treinamento. Peça uma função que renderize a entrada do usuário em uma página e você pode receber uma saída sem nenhuma codificação, abrindo a porta para cross-site scripting. Peça hashing de senha e você pode receber MD5 ou um SHA-256 puro sem salt, porque esses trechos estão por toda a internet, ainda que sejam inaceitáveis há anos.

Nenhum desses casos parece errado à primeira vista. O endpoint retorna resultados. A página renderiza. A senha "é convertida em hash". A peça que falta é o controle de segurança — consultas parametrizadas, codificação de saída, uma função moderna de derivação de chave — e o modelo não tem incentivo para adicioná-lo, a menos que você peça explicitamente.

É exatamente isso que o teste estático de segurança de aplicações (SAST) foi feito para detectar. O SAST lê o código, entende o fluxo de dados desde fontes não confiáveis até sinks sensíveis e sinaliza a injeção, a saída sem codificação, a criptografia fraca — não importa quem digitou. Quando a IA está gerando uma grande parcela dos seus commits, o SAST deixa de ser um "bom ter" e se torna o alarme que detecta os padrões que os seus desenvolvedores não escreveram e talvez não tenham lido com atenção.

Dependências alucinadas e inexistentes

Eis um modo de falha que não tem equivalente no código escrito por humanos: o modelo inventa um pacote que não existe. Você pede um utilitário para fazer o parse de algum formato, e o assistente escreve com confiança import supersecure-parser e chama funções dele. A biblioteca é plausível. A API parece razoável. E é inteiramente fictícia.

Por si só, um import alucinado apenas quebra o build. O perigo real é o que os atacantes fazem com esse padrão. Ele se chama slopsquatting: os adversários ficam de olho nos nomes de pacotes que os modelos costumam alucinar, então registram esses nomes exatos em repositórios públicos e os preenchem com código malicioso. O próximo desenvolvedor cujo assistente alucinar o mesmo nome — e os modelos alucinam os mesmos nomes com uma consistência inquietante — instala um pacote real controlado por um atacante real. Agora você tem um comprometimento da cadeia de suprimentos que começou como um autocomplete.

A defesa é a análise de composição de software (SCA) combinada com uma regra rígida de que toda dependência é verificada antes de entrar: o pacote existe? Quem o publica? Qual é a sua idade? Quão amplamente é usado? Carrega vulnerabilidades conhecidas? Uma camada de SCA que inventaria cada dependência e a confronta com a realidade detecta tanto o import alucinado quanto o genuinamente malicioso que ocupa o seu lugar — antes que ele chegue à máquina de um desenvolvedor ou aos seus servidores de build.

Vulnerabilidades herdadas dos dados de treinamento

Um assistente de IA é um espelho do código com o qual foi treinado, e boa parte desse código é antiga, desatualizada ou já era insegura desde o início. Quando um modelo reproduz um padrão que era prática-padrão cinco ou dez anos atrás, ele herda as vulnerabilidades que vinham com aquele padrão.

Você vê isso quando um assistente recorre a um algoritmo criptográfico obsoleto, fixa uma versão desatualizada de uma biblioteca com CVEs conhecidas, desabilita a verificação de certificado TLS "para funcionar" ou reproduz um fluxo de autenticação anterior às melhores práticas atuais. O código não é malicioso e não é alucinado — ele apenas está preso no passado, reproduzindo fielmente os erros de ontem porque os erros de ontem estavam bem representados no conjunto de treinamento.

Isso é uma mistura de um problema de SAST e de SCA. Configuração insegura e primitivas obsoletas aparecem na análise estática; versões de dependências desatualizadas e vulneráveis aparecem na análise de composição. O fio condutor é que você não pode contar com o modelo para saber o que "atual" significa. Ele tem um corte de treinamento e nenhuma consciência da CVE publicada na semana passada. O seu pipeline tem que fornecer essa consciência por ele.

Segredos e dados sensíveis no código gerado

Peça um exemplo funcional a um modelo e ele lhe dará um exemplo funcional — o que às vezes significa que ele preenche as lacunas com uma credencial embutida no código. O código gerado tem o hábito de embutir chaves de API de exemplo, strings de conexão com senhas inline ou tokens que parecem estrutura provisória, mas acabam sendo comitados na íntegra, porque "eu conserto depois" é uma mentira que toda base de código conta.

Há uma segunda versão, mais sutil, desse problema. Quando os desenvolvedores colam código real — incluindo segredos reais — em um assistente para pedir ajuda e depois colam a resposta de volta, as credenciais podem ser embaralhadas, duplicadas ou deixadas em um comentário. A saída gerada parece limpa, mas um segredo ativo pegou carona.

A varredura de segredos é o controle aqui, e ela precisa rodar em cada commit, idealmente no pré-commit e novamente na CI. Um scanner que reconhece formatos de credenciais e strings de alta entropia detecta a chave embutida antes que ela seja enviada — e, tão importante quanto, avisa quando um segredo real já vazou, para que você possa rotacioná-lo em vez de torcer para que ninguém tenha notado. Com a IA no fluxo gerando código repetitivo em volume, a superfície para uma credencial acidental cresce, e a revisão manual de código é a ferramenta errada para detectar um token de 40 caracteres enterrado em um bloco de configuração.

O problema do "sem proveniência, sem dono"

Dê um passo atrás em relação aos bugs individuais e há um risco estrutural por baixo de todos eles: ninguém escreveu esse código, então ninguém realmente o assume como seu. Quando um humano escreve uma função, ele carrega um modelo mental do que ela faz, por que tem aquele formato e onde estão as arestas afiadas. Quando um assistente a gera e um desenvolvedor a aceita, esse modelo mental é raso ou inexistente. O autor oficial é uma pessoa que, na prática, revisou a saída por mais ou menos o tempo que levou para apertar Tab.

Isso importa para a segurança porque a revisão é onde muitas vulnerabilidades deveriam morrer. "Quem revisa um código que nenhum humano escreveu?" não é uma pergunta retórica — é uma lacuna operacional. Falta proveniência: muitas vezes você não consegue dizer, a partir de um diff, quais linhas vieram de uma pessoa e quais vieram de um modelo, então nem sequer pode direcionar escrutínio extra ao material de maior risco. A responsabilidade é difusa: quando um trecho gerado se revela vulnerável, não há um autor que o tenha entendido bem o suficiente para ter detectado a falha.

Você não resolve uma lacuna de responsabilidade com um memorando de política. Você a resolve fazendo do próprio pipeline a rede de proteção — uma camada de segurança automatizada que trata cada alteração como não confiável e a inspeciona pelos seus méritos, para que a segurança não dependa de um humano ter entendido a fundo as linhas que aprovou.

Por que a revisão tradicional falha em detectar isso

Se a sua resposta ao código gerado por IA é "nós revisamos tudo de qualquer forma", vale ser honesto sobre por que isso está rachando sob a carga.

O primeiro problema é o volume. Os assistentes de IA não apenas ajudam os desenvolvedores a digitar mais rápido; eles mudam a unidade de trabalho de uma linha para um bloco. Uma única sugestão aceita pode ter dezenas de linhas. Multiplique isso por uma equipe e a quantidade de código que flui para a revisão por dia sobe muito além do que a leitura humana cuidadosa consegue acompanhar. Os revisores fazem triagem. Eles passam os olhos por cima. Os detalhes de segurança são exatamente o tipo de coisa que passa despercebida.

O segundo é a velocidade. Todo o propósito de um assistente de IA é comprimir o tempo entre a ideia e o commit. Essa compressão também espreme a janela de revisão. A pressão para acompanhar o desenvolvimento acelerado por IA transforma a revisão minuciosa em carimbo automático, e o carimbo automático é indistinguível de nenhuma revisão quando o assunto é segurança.

O terceiro, e mais insidioso, é o viés de automação — a bem documentada tendência humana de confiar mais em uma saída que vem de uma máquina do que confiaríamos na mesma saída vinda de uma pessoa. O código de um assistente de IA parece confiável. É sintaticamente limpo, formatado com confiança e funciona. Os revisores lhe concedem um benefício da dúvida que nunca concederiam a um pull request apressado de um colega, justamente quando deveriam ser mais céticos, não menos.

Junte esses três e a revisão manual, por si só, é estruturalmente incapaz de ser o controle de segurança para o código gerado por IA. Ela ainda é valiosa para design, correção e manutenibilidade. Ela não é um filtro confiável para falhas de injeção, criptografia fraca ou um token vazado na escala da IA. Esse trabalho precisa ser automatizado, consistente e aplicado a cada alteração sem exceção.

Como se antecipar

A lição não é "pare de usar assistentes de IA". Esse barco já partiu, e a produtividade vale a pena. A lição é que o código gerado por IA precisa do mesmo escrutínio de segurança que qualquer entrada não confiável — aplicado automaticamente, no pipeline, em cada commit.

Concretamente, isso significa o SAST detectando padrões inseguros à medida que são introduzidos, o SCA verificando cada dependência (incluindo as que não existem) e a varredura de segredos barrando credenciais antes que sejam enviadas. Significa mover essas verificações para a esquerda (shift left), para que os desenvolvedores recebam feedback no editor e no pull request, e não em um pentest trimestral. E significa tratar a saída de todo assistente como culpada até que se prove segura.

Isso é um fluxo de trabalho, não uma única configuração, e merece mais do que um parágrafo. Escrevemos um guia complementar, Como proteger o código gerado por IA, que percorre a configuração prática — onde cada controle se encaixa no pipeline, como ajustá-lo para que os desenvolvedores não se afoguem em ruído e como fechar a lacuna de proveniência. Se você está saindo do "deveríamos fazer algo a respeito" para "aqui está o nosso plano de implantação", comece por aí.

Encerramento

O código gerado por IA veio para ficar, e os seus riscos de segurança também. Os fornecedores e as equipes que sairão na frente não serão os que resistiram aos assistentes de IA — serão os que os combinaram com uma camada de segurança forte o suficiente para detectar o que a máquina erra. A Rainforest lhe dá essa camada: SAST, SCA e varredura de segredos trabalhando juntos em todo o seu pipeline, inspecionando cada commit não importa quem — ou o quê — o escreveu. Se a IA agora está escrevendo uma parcela significativa da sua base de código, é exatamente aí que compensa garantir que algo esteja verificando o trabalho dela. Veja como a Rainforest protege o código gerado por IA.