Deixou a IA corrigir a vulnerabilidade? Mais de metade dos patches não resolve nada

Uma nova investigação divulgada durante a semana da Black Hat USA 2026 mostra que confiar em modelos de linguagem para gerar correções de segurança é, para já, uma aposta arriscada. O estudo foi conduzido pela Off-By-1 Labs, a nova unidade de investigação de segurança da 1Password, que avaliou 6.080 patches gerados pelo ChatGPT 5.5 e pelo Claude Opus 4.8 para seis vulnerabilidades recentemente divulgadas em software de código aberto: 53,9% falharam a remediação da vulnerabilidade visada, introduziram uma nova vulnerabilidade ou ambas as coisas; apenas 26,0% resolveram por completo a falha sem alterar materialmente o comportamento da aplicação, e outros 20,1% resolveram-na mas mudaram a forma como a aplicação funciona. Para as organizações que já estão a automatizar a remediação com agentes de IA, a conclusão é incómoda: gerar um patch não é o mesmo que corrigir uma vulnerabilidade.

O que foi medido — e como

O artigo, intitulado «Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D.» e assinado por Axel Mierczuk, Spencer Michaels e Keith Hoodlet, parte da constatação de que uma fatia significativa do código escrito hoje vem de modelos de linguagem e de que iniciativas como o Project Glasswing, da Anthropic, e o Project Daybreak, da OpenAI, estão a estender essa tendência à identificação e remediação de vulnerabilidades. O acrónimo escolhido pelos investigadores resume a tese: FLAWED significa Fix-Like Artifacts With Embedded Defects, ou seja, artefactos com aparência de correção mas com defeitos embebidos.

A metodologia distingue este trabalho de benchmarks anteriores. A equipa escolheu vulnerabilidades novas, com baixa probabilidade de constarem dos dados de treino dos modelos, e produziu 6.080 patches em seis CVE recentemente divulgados, com dois modelos de raciocínio. Foram usados o ChatGPT 5.5 com esforço «médio» e o Claude Opus 4.8 com esforço «alto». Em vez de se limitar a verificar se o código compilava ou se passava nos testes automatizados, a equipa reviu cada correção quanto à eliminação completa da vulnerabilidade, à preservação do comportamento da aplicação e à ausência de novos riscos de segurança. Foram ainda descartadas as execuções em que os modelos tentaram localizar a correção oficial a montante em vez de resolverem o problema por si.

Os números, categoria a categoria

A repartição foi detalhada pelos investigadores: 49,3% não removeram pelo menos um caminho de ataque explorável, 2,3% corrigiram a vulnerabilidade original mas introduziram uma nova e 2,2% falharam a remediação e criaram simultaneamente uma nova fraqueza de segurança. Entre os 20,1% que corrigiram a falha alterando o comportamento da aplicação, os autores dão como exemplo lógica que passa de «lista de permissões» para «lista de negações» — um patch que fecha o CVE e parte o produto.

O problema dos patches «frágeis»

Mesmo os resultados aparentemente bem-sucedidos merecem cautela. Mais de 33% dos patches classificados nas duas categorias de sucesso continham subtilezas consideradas «frágeis» do ponto de vista de segurança: protegem contra entradas maliciosas com verificações muito específicas em vez de resolverem o código vulnerável subjacente. No caso do CVE da SpringAI, ambos os modelos geraram frequentemente correções que se limitavam a escapar determinados caracteres na entrada do utilizador, bloqueando a cadeia usada na prova de conceito apresentada ao modelo e deixando a causa-raiz intacta — se o código protegido voltar a ser alcançável por outras entradas, a vulnerabilidade ressurge. Depois de filtrar os patches frágeis, apenas cerca de 17% das correções do primeiro cenário atacavam efetivamente a causa-raiz em vez de mascararem o problema imediato, indicou Keith Hoodlet.

Os investigadores identificaram padrões recorrentes de falha, entre os quais uma «visão em túnel»: os modelos concentram-se no exploit demonstrado na prova de conceito e ignoram caminhos de código vulnerável semelhantes noutros pontos da aplicação. A equipa nota ainda que, tal como os programadores humanos, os modelos costumam precisar de orientação inicial, mas são mais facilmente descarrilados quando essa orientação está errada.

Prompts melhores ajudam, mas não eliminam o risco

Fornecer contexto mais rico melhorou o desempenho: os prompts de maior qualidade elevaram a taxa de sucesso de 51,8% para 76,3%. No entanto, prompts mais detalhados pouco fizeram para reduzir a probabilidade de introdução de novas vulnerabilidades, o que sugere que mais contexto, por si só, não elimina a tendência para correções incompletas ou frágeis. Há também um dado económico relevante para quem pondera escalar esta abordagem: o custo médio de inferência foi estimado em 2,11 dólares por tentativa de patch e ciclo de validação com o ChatGPT 5.5 e 2,81 dólares com o Claude Opus 4.8. Ainda assim, os autores sublinham que os patches produzidos por LLM continuam a exigir revisão de um engenheiro qualificado com conhecimento do domínio — e que compreender uma correção ao ponto de certificar as suas implicações de segurança dá pelo menos tanto trabalho como escrever de raiz um patch conhecido como bom.

Que software foi testado

Os modelos foram testados contra seis vulnerabilidades complexas em software amplamente utilizado, incluindo Linux, Google Chrome, Apache ActiveMQ, Spring AI, Exim e Gemini CLI, correspondendo aos identificadores acima. A investigação inclui ainda um estudo de caso sobre o servidor freenginx: a Off-by-1 Labs detetou e comunicou aos responsáveis do projeto, a 29 de junho, uma nova forma de provocar a falha do servidor, tendo a correção sido publicada a 2 de julho; depois, pôs o ChatGPT 5.5 a escrever 270 tentativas de correção para a falha original e o revisor considerou que 114 fechavam o buraco inicial — mas encontrou um novo problema em todas elas, sem qualquer resultado totalmente limpo nas 270 tentativas.

Não é um caso isolado

Outras avaliações apontam na mesma direção. O relatório «2026 GenAI Code Security Report» da Veracode, que acompanha mais de 100 modelos ao longo de quatro fotografias temporais, conclui que a taxa média de aprovação em segurança se mantém nos 56%, praticamente inalterada face ao ano anterior, com cada modelo avaliado em tarefas de geração de código em várias linguagens e categorias de vulnerabilidade, sem instruções específicas de segurança. Cerca de 44% das tarefas de geração de código introduziram uma vulnerabilidade de risco nos testes, contra 55% de taxa de aprovação no primeiro relatório. O GPT-5.5 lidera o conjunto de verão de 2026 com 68%, o Java surge em último com uma média de apenas 30%, e os modelos concebidos especificamente para código ficam-se por 51%.

Do lado académico, um estudo de larga escala sobre reparação automática de programas chega a conclusões coerentes. Analisando mais de 20 mil issues do conjunto de dados SWE-bench, investigadores da Drexel University e da Virginia Commonwealth University verificaram que um modelo autónomo (Llama 3.3) introduziu quase nove vezes mais vulnerabilidades novas do que os programadores humanos; as arquiteturas agênticas testadas — OpenHands, AutoCodeRover e HoneyComb — também geraram um número significativo de vulnerabilidades, sobretudo quando lhes foi dada mais autonomia, e as falhas foram mais prováveis em patches com mais ficheiros, mais linhas geradas e em issues sem excertos de código nem informação sobre o comportamento esperado e os passos de reprodução.

Limitações a ter em conta

Os próprios autores delimitam o alcance dos resultados. Os seis CVE foram escolhidos por serem de elevado impacto e exigirem correções complexas, em vários ficheiros, o que os torna mais difíceis do que uma vulnerabilidade aleatória — os investigadores são explícitos ao afirmar que os seus números não descrevem o «bug médio» — e as conclusões são uma fotografia de duas versões de modelos num dado momento. Para permitir verificação independente, a equipa está a disponibilizar o conjunto de dados e as ferramentas usadas, de modo a que outros possam gerar, validar, comparar e rever manualmente patches gerados por IA nos seus próprios ambientes.

O que fazer nas equipas de desenvolvimento

• Tratar qualquer correção gerada por IA como proposta, nunca como decisão: exigir revisão por um engenheiro com conhecimento do domínio antes do merge.
• Validar a causa-raiz, e não apenas a prova de conceito: testar variantes do exploit e procurar caminhos de código equivalentes no resto da aplicação.
• Não usar «passou nos testes» como critério de segurança — os testes automatizados não detetam patches frágeis nem alterações silenciosas de comportamento.
• Executar testes de regressão funcional para apanhar mudanças de comportamento, como inversões de lógica de listas de permissões.
• Limitar a autonomia dos agentes em repositórios sensíveis e registar a proveniência do código gerado por IA para efeitos de auditoria.
• Manter um SBOM atualizado e um processo formal de gestão de vulnerabilidades, independente das ferramentas de IA.

Porque é que isto importa em Portugal

Para fabricantes de software e empresas de produto sediadas em Portugal, o calendário europeu torna o tema urgente. A partir de 11 de setembro de 2026, o Regulamento Ciber-Resiliência obriga os fabricantes a notificar vulnerabilidades ativamente exploradas e incidentes graves que afetem a segurança de produtos com elementos digitais, com um alerta inicial em 24 horas, notificação completa em 72 horas e relatório final até 14 dias após a disponibilização de uma medida corretiva, através da plataforma única de notificação. O regulamento entrou em vigor a 10 de dezembro de 2024 e a generalidade das restantes obrigações aplica-se a partir de 11 de dezembro de 2027. Um patch aplicado à pressa que não elimina o caminho de ataque — ou que abre outro — pode transformar-se, nesse quadro, num problema de conformidade e não apenas técnico.

A isto junta-se, no plano nacional, o Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2 e reforça as exigências de gestão de risco e de comunicação de incidentes junto do CNCS e do CERT.PT para as entidades abrangidas. Se uma remediação defeituosa deixar exposta uma aplicação que trata dados pessoais, o incidente pode ainda desencadear obrigações de notificação à CNPD ao abrigo do RGPD. Para as PME, a mensagem é a mesma que vale para as grandes organizações: a IA pode acelerar a produção de correções, mas a responsabilidade pelo software que entra em produção continua a ser de quem o publica.

Perguntas frequentes

O que significa um patch «FLAWED»?

É o acrónimo proposto pelos investigadores para Fix-Like Artifacts With Embedded Defects: código que se parece com uma correção mas que traz defeitos embebidos, seja por não fechar todos os caminhos de exploração, seja por criar uma nova fraqueza.

Devo deixar de usar IA para corrigir vulnerabilidades?

Não é essa a conclusão do estudo. A mensagem é que os patches gerados por IA não substituem a revisão especializada: os engenheiros continuam a ter de verificar que a correção elimina a causa-raiz, preserva o comportamento pretendido da aplicação e não introduz novas vulnerabilidades antes de ser implementada.

Melhorar os prompts resolve o problema?

Ajuda, mas não chega. Os prompts de maior qualidade fizeram subir a taxa de sucesso de 51,8% para 76,3%, embora tenham feito pouco para reduzir a probabilidade de introdução de novas vulnerabilidades.

Isto afeta a conformidade das empresas portuguesas?

Pode afetar. Desde 11 de setembro de 2026, os fabricantes têm de notificar vulnerabilidades ativamente exploradas e incidentes graves em produtos com elementos digitais, e as entidades abrangidas pelo Regime Jurídico da Cibersegurança respondem perante o CNCS pela gestão do risco, incluindo a qualidade das correções que aplicam.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Off-By-1 Labs (1Password), pela Veracode, por investigadores da Drexel University e da Virginia Commonwealth University e pela Comissão Europeia.