O código gerado por IA é seguro? O que as medições dizem, e o que escapa aos scanners

O código gerado por IA é seguro?

Não, não por omissão. O código gerado por IA é tão seguro quanto os controlos à volta dele, e a maioria das montagens não tem controlo nenhum antes de o código aterrar. Os benchmarks independentes concordam na forma da falha: o código corre, passa nos testes e leva uma vulnerabilidade na mesma. A segurança é uma propriedade da tua pipeline, não do modelo.

A medição mais antiga continua a ser a mais clara. Em Asleep at the Keyboard, submetido em agosto de 2021 por uma equipa da New York University com um co-autor na University of Calgary, os investigadores puseram o GitHub Copilot a completar 89 cenários do Top 25 de fraquezas da MITRE e recolheram 1 689 programas. A conclusão, nas palavras deles: «Of these, we found approximately 40% to be vulnerable.» O número tem cinco anos e fala de um único assistente, por isso trata-o como linha de base e não como o veredito de hoje.

O veredito de hoje vem do SusVibes, um benchmark do Language Technologies Institute da Carnegie Mellon com a Columbia, a Johns Hopkins e a HydroX AI, aceite na ICML 2026 e revisto a 21 de agosto de 2026. Parte de 186 pedidos de funcionalidade reais, tirados de projetos open source onde a própria implementação humana era vulnerável, cobre 79 categorias CWE e põe 12 configurações de agente a resolvê-los. A melhor, o SWE-Agent com o Claude 4 Sonnet, ficou funcionalmente correta em 57% das tarefas e segura em 11,8%. E acrescenta a linha que te devia tirar o sono: 79,3% das soluções funcionalmente corretas levam uma vulnerabilidade.

11,8%

das soluções do melhor agente eram seguras, face a 57% funcionalmente corretas (SusVibes, 186 pedidos de funcionalidade reais, revisto em agosto de 2026)

79,3%

das soluções funcionalmente corretas desse mesmo agente levavam, ainda assim, uma vulnerabilidade (mesmo benchmark)

100%

das aplicações testadas pela OWASP apresentavam alguma forma de controlo de acesso quebrado, o seu risco número um para 2025

A escala é o que transforma uma taxa por tarefa num problema de negócio. No relatório DORA de 2025 sobre desenvolvimento assistido por IA, publicado a 23 de setembro de 2025, «90% of survey respondents report using AI at work» e «30% report little or no trust in the code generated by AI». O mesmo relatório regista que «AI adoption does continue to have a negative relationship with software delivery stability». Nove em cada dez já entregam código escrito com IA, três em cada dez não confiam nele, e é na estabilidade da entrega que a tensão aparece. Nota, para o equívoco fácil por cá: este DORA é o DevOps Research and Assessment da Google Cloud, não o regulamento europeu homónimo.

Por que razão é que tanto código gerado por IA é inseguro?

Porque um modelo consegue ter o princípio de segurança na cabeça e falhar em aplicá-lo na linha onde ele conta. Uma sistematização de junho de 2026 da University at Buffalo deu nome a isto, a lacuna entre conhecimento e atuação, e mediu-a: os modelos pontuam muito mais alto a saber a regra do que a escrever código que sobrevive ao exploit. Saber não é fazer.

Esse trabalho, o SoK: AI Secure Code Generation, põe números na distância. «The benchmark-level gap is 47.9 points for CWEval and 72.9 points for BaxBench», e a lacuna alarga-se à medida que a tarefa se aproxima do mundo real: o CWEval avalia ao nível da função, o BaxBench pede aplicações web inteiras, onde a guarda tem de aterrar no middleware certo, na rota certa, no ficheiro certo. A décima terceira conclusão do artigo é a frase a reter: a lacuna é um problema de entrega, os modelos têm o conhecimento de segurança certo e falham em aplicá-lo na fronteira de implementação correta. O que resulta é ligar um princípio conhecido ao sítio certo do código, não ensinar mais segurança ao modelo.

Duas forças mais antigas agravam o quadro. O corpus: o modelo aprendeu com código público cheio de SQL concatenado, autorização em falta, criptografia fraca e segredos escritos à mão no ficheiro, por isso inseguro por omissão é o seu prior estatístico. E a ausência: a segurança é quase sempre uma guarda que está presente, e um modelo a quem se pede um resultado positivo ("acrescenta um endpoint de checkout") não acrescenta a guarda negativa que ninguém pediu. A funcionalidade funciona precisamente porque a verificação que falta não toca no caminho feliz.

Depois há o leitor, e é o fator decisivo. Quem escreve o prompt consegue dizer se a funcionalidade funciona, raramente se é segura. Essa distância, entre a intenção de quem escreve e a capacidade de quem revê, é todo o problema de segurança, e alarga-se quando alguém sem especialidade faz vibe coding a partir de um parágrafo de intenção. Aprofundamos isto em segurança do vibe coding.

Que tipos de vulnerabilidades introduz o código de IA?

As mesmas que os humanos introduzem, reproduzidas mais depressa do que a revisão consegue acompanhar. Injeção, autorização quebrada, segredos embutidos, validação de input em falta, desserialização insegura e erros de lógica de negócio. Quase todas estão no CWE Top 25 de 2025, e o ponto é esse: não são falhas exóticas de modelo, são as fraquezas mais antigas da indústria.

• Injeção (CWE-89, CWE-78). SQL e comandos de shell concatenados a partir de input do utilizador, aprendidos de um corpus cheio deles. A injeção de SQL é a segunda e a injeção de comandos do sistema operativo a nona no CWE Top 25 de 2025. Vê por que razão a maioria das descobertas de SAST é ruído para perceber por que só as alcançáveis contam.
• Autorização quebrada e IDOR (CWE-862, CWE-639). O agente constrói o endpoint que devolve o registo, raramente a verificação de que quem chama é o dono. A autorização em falta é a quarta da mesma lista, e a OWASP põe a categoria-mãe à frente de tudo: sobre a A01:2025 Broken Access Control escreve que está «maintaining its position at #1 in the Top Ten» e que «100% of the applications tested» apresentavam alguma forma dela.
• Segredos embutidos no código (CWE-798). Pede-lhe uma integração que funcione e ele embute uma chave de API ou uma palavra-passe para o código correr à primeira, e ela passa a viver no repositório e em cada fork. Esta classe não consta do CWE Top 25 de 2025, por isso não é nesse ranking que a vais encontrar.
• Validação de input em falta (CWE-20). Os endpoints gerados confiam nos seus inputs, o facilitador silencioso da injeção e da desserialização a jusante. É a décima oitava da lista de 2025.
• Desserialização insegura (CWE-502). "Carrega o objeto guardado" torna-se pickle ou yaml.load sobre bytes não confiáveis, e transforma um blob armazenado em execução remota de código. É a décima quinta de 2025.
• Falhas de lógica de negócio. A classe mais perigosa, porque nenhum scanner está talhado para a apanhar: um carrinho com quantidade negativa, um cupão que se acumula, um reembolso que salta a verificação de propriedade. Sintaticamente perfeito, semanticamente errado, e fora de qualquer ranking CWE porque é específico do teu domínio. Este é o nosso aprofundamento sobre falhas de lógica de negócio no código gerado por IA.

O que escapa aos scanners, e aos próprios modelos?

Duas coisas. A lógica de negócio, que não oferece sink perigoso a que casar um padrão, e os pontos cegos do modelo, que ele não consegue auditar enquanto continuarem lá. O SusVibes mediu o segundo diretamente: acrescentar pistas de vulnerabilidade ao pedido de funcionalidade não mitigou os problemas de segurança, logo insistir no prompt não é a correção.

O primeiro ponto cego é a lógica de negócio. Um analisador estático raciocina sobre padrões de código; uma regra de negócio ("só o dono pode editar este documento", "a quantidade tem de ser positiva") vive fora do código, no teu domínio. Não há input contaminado nem sink perigoso a que corresponder, há apenas um if que nunca foi escrito, e o scanner reporta o ficheiro como limpo enquanto ele é totalmente explorável.

O segundo é o modelo a corrigir os seus próprios trabalhos de casa. Pedir ao agente que escreveu o código que o reveja herda os mesmos pontos cegos: não conhece o teu modelo de autorização, não vê as outras descobertas à volta da linha, e está tão confiante na versão insegura como na segura. É outra vez a lacuna entre conhecimento e atuação, vista do lado da revisão. Uma verificação em que possas confiar precisa de sinal de fora: análise consciente da alcançabilidade que segue o fluxo de dados real, e as tuas regras carregadas como verdade de base.

“

A questão não é se a IA escreve código inseguro, todos os autores o fazem. É se alguma coisa apanha a linha insegura antes de ela ser entregue, e à velocidade da IA o único sítio que resta para a apanhar é onde a linha é escrita.

Podes confiar numa IA para corrigir as suas próprias vulnerabilidades?

Podes confiar num agente para aplicar uma correção muito mais do que para decidir o que é uma vulnerabilidade real e alcançável. Ele reescreve bem uma linha assim que sabe o que mudar, e julga mal a explorabilidade, que é precisamente o que um scanner já calculou. Por isso dá-lhe descobertas confirmadas e ordenadas por alcançabilidade mais as tuas regras, deixa-o corrigir, e aprova cada diff.

Cobrimos esse ciclo em remediação de vulnerabilidades com IA e em encontrar e corrigir vulnerabilidades automaticamente.

O que não funciona é escrever as regras num ficheiro e ficar à espera. No nosso estudo controlado de 24 de agosto de 2026, 30 tickets de desenvolvimento correram em triplicado sobre uma base de código de dimensão média, 90 execuções autónomas e 93 análises de segurança independentes, com o Claude Opus 5 em esforço elevado. Um ficheiro de regras realista, mantido à mão no repositório, implementou exatamente 7 de 55 especificidades de regra, 13%, contra 8 de 65 sem ficheiro nenhum, 12%. O ficheiro não mudou quase nada. As mesmas regras entregues no momento da edição chegaram a 57 de 64, 89%.

O estudo publica também os seus limites, e convém lê-los antes do número bonito: um ticket em que o braço sem ferramenta nenhuma se saiu melhor; outro em que a regra foi servida treze vezes e o agente desmontou na mesma as suas próprias guardas; e um protocolo que mede a capacidade de ficar em zero numa base que começou limpa, não a de sair de uma dívida já acumulada.

Como é que tornas o código gerado por IA seguro?

Mudando o controlo para o momento em que o código é escrito, e mantendo a análise e a revisão humana atrás dele. Três movimentos, por ordem de alavancagem: governar o que o agente escreve antes de ele escrever, devolver-lhe as descobertas confirmadas dos scanners, e guardar um gate no CI mais um humano a aprovar diffs.

1. Governar no momento da geração. Carrega as tuas regras de segurança e de negócio no agente antes de cada edição, para que o padrão seguro seja o que ele usa por omissão. A vulnerabilidade que nunca é escrita não precisa de triagem. É esta a ideia central de segurança de agentes de código de IA.
2. Analisar continuamente e devolver as descobertas ao agente. Mantém SAST consciente da alcançabilidade, SCA, segredos, IaC e CI/CD a correr, e põe as descobertas confirmadas nas mãos do agente para ele remediar as reais no ciclo. No nosso estudo, as novas descobertas de segurança introduzidas por tarefa caíram de 0,10 sem ferramenta para 0,033 com a camada, e a contagem do scanner independente passou de 1 para 4 no braço sem assistência ao longo de trinta tickets, enquanto o braço governado ficou em 1.
3. Manter o CI e a revisão humana como rede de segurança. Um gate de SAST em cada pull request e um humano a aprovar diffs apanham o que escapa. Necessários, mas à velocidade da IA não podem ser a única linha.

A versão prática está em como acrescentar segurança ao teu fluxo de trabalho com IA e em como proteger uma aplicação inteira em cinco minutos.

O VibeDefend é a camada que faz os dois primeiros. É uma CLI npm gratuita que instala em segundos e liga o Claude Code, o Cursor, o Windsurf, o OpenAI Codex e o VS Code Copilot a quatro camadas de governação dentro do ciclo do agente.

Três camadas governam o que o agente escreve: as Business Rules extraídas do teu repositório, as Security Rules das famílias OWASP, SOC 2, RGPD e ISO 27001, e um Action Guard que bloqueia chamadas destrutivas. A quarta, as Live Findings, liga o agente à plataforma de análise da CybeDefend, com SAST, SCA, segredos, IaC e CI/CD a correr continuamente e cada descoberta ao vivo no seu contexto, de modo que não só escreve código mais seguro como corrige as vulnerabilidades que já lá tens. Nada do teu código atravessa a rede; só metadados de governação estruturados o fazem, em regiões da UE ou dos EUA mantidas fisicamente separadas.

Perguntas frequentes

Respostas curtas, assentes nas fontes ligadas acima: o estudo da New York University sobre o Copilot, de 2021, o SusVibes revisto em agosto de 2026, a sistematização da University at Buffalo de junho de 2026, o OWASP Top 10:2025 e o nosso estudo controlado de 24 de agosto de 2026.

O código gerado por IA é seguro?

Não por omissão. Corre e passa no caminho feliz, mas os testes independentes encontram repetidamente uma grande parte dele insegura: cerca de 40% das sugestões do GitHub Copilot eram vulneráveis no estudo "Asleep at the Keyboard" da New York University, de 2021, e no SusVibes revisto em agosto de 2026 a melhor configuração de agente esteve funcionalmente correta em 57% dos pedidos e apenas 11,8% das suas soluções eram seguras. Torna-se seguro com um controlo que age onde o código é escrito, e revisão humana e análise no CI por trás.

É seguro colocar código gerado por IA em produção?

Só depois de revisto e analisado como qualquer código, e de preferência depois de governado enquanto era escrito. É arriscado entregar a partir do "funciona": as falhas (autorização em falta, injeção, segredos embutidos, erros de lógica de negócio) não tocam no caminho feliz e sobrevivem a um teste funcional. O SusVibes mediu essa distância: 79,3% das soluções funcionalmente corretas do melhor agente levavam na mesma uma vulnerabilidade. Fecha-o com SAST consciente da alcançabilidade no CI, revisão humana dos caminhos sensíveis, e um controlo no momento do prompt.

Por que razão é que o código gerado por IA é inseguro, se o modelo é tão capaz?

Porque produzir código que funciona não é o mesmo que produzir código seguro. A sistematização da University at Buffalo de junho de 2026 chama a isto a lacuna entre conhecimento e atuação, e mediu-a em 47,9 pontos no CWEval e 72,9 pontos no BaxBench: o modelo sabe o princípio e falha em aplicá-lo na fronteira de implementação certa. Junta-lhe o corpus (código público cheio de padrões inseguros), a ausência (uma guarda que ninguém pediu) e o leitor (quem escreve o prompt raramente avalia se o resultado é seguro). Nada disto se resolve com um modelo mais inteligente.

Posso simplesmente pedir à IA que verifique o seu próprio código?

Ajuda um pouco e não chega. O modelo que escreveu o código partilha os seus pontos cegos: não conhece o teu modelo de autorização nem a fronteira entre tenants, não vê as outras descobertas à volta da linha, e está igualmente confiante nas duas versões. O SusVibes testou o atalho óbvio: acrescentar pistas de vulnerabilidade ao pedido de funcionalidade não mitigou os problemas de segurança. Uma verificação fiável precisa de sinal de fora, análise da alcançabilidade e as tuas regras como verdade de base.

Quais são as vulnerabilidades mais comuns no código gerado por IA?

Injeção (CWE-89, CWE-78), autorização quebrada e IDOR (CWE-862, CWE-639), segredos embutidos no código (CWE-798), validação de input em falta (CWE-20), desserialização insegura (CWE-502) e falhas de lógica de negócio. Quatro destas seis classes estão no CWE Top 25 de 2025, e a OWASP põe o controlo de acesso quebrado em primeiro lugar para 2025, reportando 100% das aplicações que testou com alguma forma dele. As primeiras cinco são detetáveis por bons scanners quando filtras por alcançabilidade; a última é a perigosa, porque nenhum scanner apanha uma regra sintaticamente perfeita e semanticamente errada.

Como é que torno o código gerado por IA seguro?

Muda o controlo para o momento da geração: carrega as tuas regras de segurança e de negócio no agente para ele escrever primeiro o padrão seguro, analisa continuamente e devolve-lhe as descobertas confirmadas, e mantém um gate de SAST no CI mais revisão humana como rede de segurança. Escrever as regras num ficheiro não chega: no nosso estudo controlado de 24 de agosto de 2026, um ficheiro de regras realista implementou exatamente 7 de 55 especificidades de regra, 13%, contra 8 de 65 sem ficheiro nenhum, 12%, enquanto as mesmas regras entregues no momento da edição chegaram a 57 de 64, 89%.