Patches gerados por IA falham em 54% dos casos: estudo expõe riscos e limitações dos LLMs na correção de falhas
Um estudo recente da Off-by-1 Labs, equipe de pesquisa da 1Password, jogou um balde de água fria na ideia de que modelos de linguagem de grande porte (LLMs) já estão prontos para assumir, sozinhos, a correção de vulnerabilidades em código. De acordo com o relatório, em 53,9% das tentativas os patches sugeridos por IA para falhas complexas simplesmente não funcionam ou acabam criando novos problemas de segurança.
Os pesquisadores analisaram 6.080 patches gerados por modelos de IA de duas grandes empresas do setor para corrigir seis vulnerabilidades recentemente divulgadas em projetos de software open source. O objetivo era medir, na prática, o quanto esses sistemas conseguem apoiar o trabalho de engenheiros de segurança e desenvolvedores na etapa mais crítica do ciclo de resposta a incidentes: a correção.
Taxa de sucesso é baixa – e o risco de impacto colateral é alto
Os resultados foram claros. Em média, apenas 26,0% dos patches produzidos pelos LLMs realmente corrigiam a vulnerabilidade e, ao mesmo tempo, preservavam o comportamento esperado da aplicação. Ou seja, somente em cerca de um quarto dos casos o código gerado pela IA entregou o que qualquer equipe de desenvolvimento considera o cenário ideal: falha resolvida, sistema funcionando exatamente como antes, sem efeitos colaterais.
Em 20,1% das tentativas, os patches até eliminavam a vulnerabilidade principal, mas alteravam o comportamento da aplicação. Entre os impactos identificados, os pesquisadores citam, por exemplo:
– reimplementação de parsers locais de forma desnecessária ou arriscada;
– mudanças na lógica de controle de acesso, como troca de listas de permissão (allowlist) por listas de negação (denylist);
– modificações em fluxos de processamento que não faziam parte do escopo da correção.
Esse tipo de alteração, ainda que bem-intencionada pela IA, pode introduzir regressões, abrir novas brechas de segurança ou afetar a experiência do usuário. Em ambientes de produção críticos, pequenas mudanças comportamentais podem gerar interrupções, incompatibilidades com outros sistemas e impactos financeiros imediatos.
F.L.A.W.E.D.: quando o patch “parece bom”, mas está quebrado
Para descrever esses patches que aparentam ser correções válidas, mas são enganosos, os pesquisadores criaram o termo F.L.A.W.E.D. – sigla para “Fix-Like Artifacts with Embedded Defects” (algo como “artefatos parecidos com correções, mas com defeitos embutidos”).
Na prática, um patch F.L.A.W.E.D. é aquele que:
– visualmente se parece com uma correção legítima;
– passa em alguns testes simples ou no proof-of-concept (PoC) conhecido;
– mas, sob análise detalhada, deixa brechas abertas, não elimina a causa raiz ou insere novos vetores de ataque.
Esses artefatos são especialmente perigosos porque transmitem uma falsa sensação de segurança. Uma equipe pressionada por prazos pode aceitar uma correção “aparentemente correta”, aplicar em produção e seguir adiante, sem perceber que o problema persiste – ou pior, que foi ampliado.
Custo por tentativa é baixo, mas o barato pode sair caro
O estudo também avaliou o custo financeiro direto de tentar gerar patches por meio de LLMs. Em média, cada tentativa de correção custou 2,11 dólares para o modelo de uma das empresas e 2,81 dólares para o modelo da outra. À primeira vista, esses valores são baixos se comparados ao custo-hora de um engenheiro de segurança ou desenvolvedor experiente.
No entanto, o levantamento mostra que o “custo real” não está apenas no valor por requisição, e sim no retrabalho e na possível exposição residual. Mais de um terço (mais de 33%) dos patches classificados como bem-sucedidos eram, na verdade, correções “frágeis”: funcionavam apenas para um cenário muito específico, sem tratar de forma abrangente a causa estrutural da vulnerabilidade.
Em outras palavras, a IA muitas vezes “aprende a passar no teste”, mas não aprende a resolver o problema de verdade. Na correção de uma vulnerabilidade em SpringAI, por exemplo, os modelos geraram patches que apenas escapavam caracteres específicos da entrada do usuário. Isso foi suficiente para bloquear o ataque da prova de conceito usada na avaliação, mas não eliminou o padrão de insegurança que tornava o componente vulnerável a explorações semelhantes.
O papel insubstituível da revisão humana
Diante desse cenário, a recomendação central da 1Password é direta: a intervenção humana continua indispensável no processo de correção de vulnerabilidades. Segundo a empresa, com as capacidades atuais dos modelos de IA, é fundamental que um engenheiro ou especialista em segurança revise cada patch proposto.
Essa revisão não se limita a “ver se o código compila”. Ela envolve:
– entender o contexto da vulnerabilidade e do sistema afetado;
– verificar se a lógica da aplicação foi preservada;
– avaliar se a correção trata a causa raiz e não apenas o sintoma;
– checar se não foram introduzidas novas superfícies de ataque, como bypasses, condições de corrida ou problemas de autorização.
Os pesquisadores ressaltam que, para equipes maduras em segurança, a IA deve ser vista como um assistente que acelera tarefas repetitivas – geração de esboços de patches, criação de testes adicionais, refatoração de trechos específicos – e não como um substituto completo da análise humana.
Ferramenta FLAWED: testando a eficácia dos LLMs no seu próprio código
Como desdobramento do estudo, a 1Password também desenvolveu e disponibilizou um conjunto de ferramentas batizado de FLAWED. O objetivo é permitir que organizações façam seus próprios experimentos, avaliando como determinados modelos de IA se comportam diante de vulnerabilidades reais em seus códigos internos.
Com esse tipo de tooling, equipes de segurança podem:
– simular cenários de correção com diferentes modelos e configurações;
– medir taxas de sucesso, de falhas e de patches F.L.A.W.E.D.;
– identificar padrões de erro recorrentes da IA em determinadas linguagens, frameworks ou tipos de vulnerabilidade;
– definir políticas internas sobre quando e como é aceitável usar inteligência artificial em correções.
Isso ajuda a separar hype de resultado concreto e traz dados objetivos para a discussão sobre investimento em tecnologias de IA na área de segurança de software.
O novo gargalo da segurança: verificação, divulgação e correção
Um dos pontos mais interessantes destacados no relatório é a mudança de paradigma sobre o que, hoje, limita o avanço em segurança de software. Tradicionalmente, o gargalo estava na descoberta de novas vulnerabilidades: encontrar bugs complexos exigia análises manuais demoradas, testes especializados e muita experiência acumulada.
Com o amadurecimento de ferramentas automatizadas, scanners e, mais recentemente, LLMs aplicados à análise de código, a descoberta se tornou mais rápida. Em muitos contextos, o que passa a limitar o progresso não é mais “encontrar a falha”, e sim:
– verificar cuidadosamente cada descoberta;
– avaliar impacto, prioridade e contexto de negócio;
– divulgar de forma responsável para equipes internas e, quando necessário, para terceiros;
– desenvolver, validar e aplicar o patch com segurança.
De acordo com o estudo, o progresso agora está condicionado à velocidade e à qualidade com que essas etapas posteriores são cumpridas – algo que a IA, isoladamente, ainda não consegue resolver.
Como as empresas podem usar IA em segurança sem cair na armadilha dos F.L.A.W.E.D. patches
Para organizações que desejam aproveitar os ganhos de produtividade da IA sem se expor aos riscos identificados, algumas boas práticas se destacam:
1. Definir claramente o papel da IA
Tratar os LLMs como ferramentas de apoio, e não como “autores finais” de correções. A IA pode sugerir caminhos, mas a decisão final precisa de validação humana.
2. Integrar IA ao pipeline de desenvolvimento seguro (SSDLC)
Em vez de usar a IA de forma ad hoc, é mais eficaz integrá-la a estágios específicos do ciclo: apoio na escrita de testes, sugestão de mitigação inicial, análise de impacto, documentação técnica.
3. Criar políticas internas para uso de patches gerados por IA
Por exemplo, exigir obrigatoriamente revisão por um engenheiro sênior para qualquer patch proposto pela IA; proibir deploy direto em produção; definir tipos de vulnerabilidade em que o uso da IA é permitido ou desencorajado.
4. Fortalecer a cultura de testes automatizados
Quanto mais robusta for a suíte de testes (unitários, de integração, de segurança), maior a capacidade de detectar efeitos colaterais introduzidos pelos patches gerados por IA.
5. Registrar métricas de eficácia da IA ao longo do tempo
Acompanhar taxas de sucesso, retrabalho, incidentes pós-correção e tempo médio de validação ajuda a entender se a adoção da IA está de fato entregando valor.
Impacto para desenvolvedores e equipes de segurança
Para desenvolvedores, o estudo é um alerta para não terceirizar completamente o raciocínio de engenharia. A tendência de “pegar o patch pronto da IA e colar” precisa ser substituída por uma postura mais crítica: analisar diffs com cuidado, questionar mudanças amplas demais, simular cenários adversos.
Já para equipes de segurança, os dados reforçam a importância de investir em habilidades de revisão e de engenharia de correção, não apenas em detecção. Em muitos casos, a criação de uma cultura de “code review de segurança” estruturado – com checklists, critérios de aceitação e envolvimento de diferentes perfis – tem impacto maior do que simplesmente adicionar mais ferramentas ao stack.
O futuro: modelos especializados e automação supervisionada
Embora o estudo aponte limitações significativas dos LLMs atuais, ele não fecha a porta para o uso da IA em correção de vulnerabilidades. Pelo contrário, sugere que o caminho mais promissor está em:
– modelos especializados em segurança, treinados com foco em padrões de vulnerabilidade e correção segura;
– uso intensivo de testes automatizados guiados por IA para validar patches;
– workflows de automação supervisionada, em que a IA propõe, testa e documenta, mas a decisão final é humana.
À medida que novos modelos surgirem e forem treinados com dados mais específicos de segurança de software, é provável que a taxa de sucesso melhore. Ainda assim, o papel do engenheiro continuará central, sobretudo em sistemas complexos, legados ou com requisitos regulatórios rigorosos.
Conclusão: IA acelera, mas não substitui a engenharia de segurança
Os números do estudo da Off-by-1 Labs deixam claro que, hoje, confiar cegamente em patches gerados por IA é um risco que poucas organizações podem assumir. Com uma taxa de falha próxima de 54% e uma parcela considerável de correções frágeis mesmo entre as consideradas “bem-sucedidas”, a mensagem é inequívoca: a IA é poderosa, mas ainda não é confiável o suficiente para operar sozinha na linha de frente da correção de vulnerabilidades.
O uso responsável dessa tecnologia passa por combiná-la com processos maduros, revisão humana rigorosa e uma cultura em que velocidade e segurança caminham juntas – sem atalhos que troquem eficiência aparente por exposição silenciosa.