Patches criados por IA falham em mais da metade dos casos e exigem revisão humana rigorosa
Um estudo recente da Off-by-1 Labs, equipe de pesquisa da 1Password, acendeu um alerta importante para quem aposta em inteligência artificial generativa como solução automática para corrigir vulnerabilidades de software. A análise mostrou que, em 53,9% das vezes, os patches produzidos por modelos de linguagem (LLMs) para falhas complexas não só não resolvem o problema como podem introduzir novos riscos de segurança.
Os pesquisadores avaliaram 6.080 patches gerados por modelos de duas grandes fornecedoras de IA – OpenAI e Anthropic – aplicados a seis vulnerabilidades recentes em projetos de código aberto. Ou seja, não se tratava de exercícios artificiais, mas de falhas reais, presentes em softwares utilizados na prática.
Nível de eficácia: menos de um terço de sucesso “limpo”
O levantamento mostrou que a taxa média de sucesso para um patch verdadeiramente eficaz – isto é, aquele que corrige completamente a vulnerabilidade sem alterar o comportamento esperado da aplicação – foi de apenas 26,0%. Em outras palavras, em pouco mais de um quarto das tentativas a IA conseguiu produzir uma correção tecnicamente aceitável e funcional, sem efeitos colaterais relevantes.
Em 20,1% dos casos, os patches gerados conseguiram, de fato, mitigar a vulnerabilidade principal. Porém, ao custo de modificar o comportamento da aplicação de forma significativa. Essas alterações incluíam, por exemplo:
– Reimplementação de parsers locais de forma desnecessária;
– Mudança em mecanismos de autorização, trocando lógicas baseadas em listas de permissão (allow lists) por listas de negação (deny lists);
– Ajustes estruturais no código que iam além do escopo da correção.
Na prática, esses patches “meio certos” podem resolver o problema imediato de segurança, mas abrem espaço para regressões, bugs funcionais ou até novas brechas, por alterarem partes críticas do sistema sem uma compreensão plena do contexto.
O conceito de F.L.A.W.E.D.: correções com defeitos embutidos
A partir desses achados, os pesquisadores introduziram o termo F.L.A.W.E.D. – sigla para “Fix-Like Artifacts with Embedded Defects”. A expressão descreve um fenômeno recorrente: a IA produz algo que se parece com uma correção, passa em testes superficiais, mas contém erros sutis ou novas vulnerabilidades.
Em outras palavras, o patch pode:
– Não eliminar a causa raiz do problema;
– Ser efetivo apenas contra um cenário de ataque específico;
– Criar um novo vetor de exploração, frequentemente mais difícil de detectar;
– Comprometer a integridade ou a confiabilidade do software.
Esse tipo de “correção aparente” é particularmente perigoso em segurança: a organização pode acreditar que está protegida, relaxar controles de monitoramento e, na prática, continuar exposta – às vezes de forma ainda mais frágil do que antes.
Fragilidade oculta até mesmo nos patches “bem-sucedidos”
Outro resultado preocupante do estudo é que mais de 33% dos patches classificados como bem-sucedidos apresentavam fragilidades sutis. Ou seja, mesmo quando o modelo de IA acerta tecnicamente, muitas vezes o faz de forma parcial ou frágil.
Um caso ilustrativo citado no relatório envolve uma vulnerabilidade no SpringAI. Em vez de corrigir o problema na sua origem – por exemplo, ajustando a forma como a aplicação valida e sanitiza entradas – os modelos passaram a escapar caracteres específicos utilizados no ataque de prova de conceito (proof-of-concept).
Na prática, o que isso significa?
– O patch bloqueava o ataque demonstrado pelo pesquisador;
– Mas não protegia contra variantes do mesmo ataque com pequenas modificações;
– A lógica de segurança continuava dependente de uma lista limitada de caracteres problemáticos, deixando a superfície de ataque aberta.
Esse tipo de correção “de vitrine” é típico de abordagens automáticas que se concentram em bloquear o exemplo visto, e não em entender o padrão de vulnerabilidade subjacente.
Custo dos patches: barato por tentativa, caro se mal aproveitado
O estudo também avaliou o custo médio por tentativa de patch. Segundo os dados apresentados, cada tentativa custou em torno de 2,11 dólares para o modelo da OpenAI e 2,81 dólares para o modelo da Anthropic. Do ponto de vista financeiro, o preço por patch parece baixo, o que pode estimular organizações a gerar centenas ou milhares de correções automaticamente.
No entanto, o custo real não está apenas no valor da chamada ao modelo, mas no que acontece depois:
– Tempo gasto por engenheiros analisando patches falhos ou parcialmente corretos;
– Risco de implantar correções com defeitos que exigirão retrabalho;
– Possibilidade de incidentes de segurança ou de disponibilidade decorrentes de patches mal testados;
– Aumento da complexidade do código base, dificultando manutenção futura.
Assim, embora o custo unitário seja atraente, a adoção de patches gerados por IA sem um processo de validação robusto pode sair muito mais caro no médio prazo.
Papel indispensável da revisão humana
Diante do cenário mapeado pela Off-by-1 Labs, a recomendação central é clara: a revisão humana deve continuar no centro do processo de correção de vulnerabilidades. A 1Password ressalta que, com as capacidades atuais dos modelos, é essencial que engenheiros experientes:
– Avaliem se o patch de fato elimina a vulnerabilidade;
– Verifiquem se não há impactos indesejados no comportamento da aplicação;
– Analise se a correção trata a causa raiz, e não apenas o sintoma;
– Realizem code review e testes de regressão adequados.
A IA pode ser uma aliada poderosa para acelerar a proposta de soluções, sugerir caminhos ou automatizar partes repetitivas do trabalho. Mas não está pronta para substituir o julgamento técnico e o senso crítico de profissionais de segurança e desenvolvimento.
Ferramenta FLAWED: medindo a eficácia da IA no seu próprio código
Como desdobramento do estudo, a 1Password apresentou um conjunto de ferramentas chamado FLAWED, criado para que empresas possam avaliar, na prática, a performance de LLMs aplicados ao seu próprio código.
A ideia é que as organizações:
– Testem diferentes modelos em cenários controlados;
– Avaliem taxas de sucesso de patches em vulnerabilidades reais;
– Identifiquem padrões de erros repetidos produzidos pela IA;
– Definam limites claros para o uso de automações em correção de falhas.
Esse tipo de abordagem permite que cada equipe construa seus próprios parâmetros de confiança, em vez de assumir que “se veio da IA, está certo”.
A nova limitação da segurança de software: verificação, não descoberta
Um ponto interessante levantado pela 1Password é a mudança de gargalo na segurança de software. Tradicionalmente, o grande desafio era a identificação de novas vulnerabilidades. Hoje, com o avanço de ferramentas de análise estática, scanners e até modelos de IA que sugerem possíveis falhas, o problema se desloca.
Segundo o estudo, o progresso em segurança está cada vez mais limitado por:
– Velocidade com que é possível verificar se uma correção é realmente eficaz;
– Tempo necessário para revisar e validar patches;
– Capacidade das equipes de priorizar o que deve ser corrigido primeiro;
– Processo de divulgação responsável de vulnerabilidades e atualizações.
Ou seja, encontrar problemas está cada vez mais fácil; corrigi-los com segurança continua sendo o verdadeiro desafio.
Como as empresas podem usar IA em patches sem aumentar o risco
Para aproveitar o potencial da IA em correção de vulnerabilidades sem cair nas armadilhas apontadas pelo estudo, algumas práticas são recomendáveis:
1. Usar a IA como assistente, não como autoridade final
Tratar o patch sugerido pelo modelo como um “rascunho inteligente”, a ser refinado por desenvolvedores e especialistas em segurança.
2. Integrar geração de patches ao pipeline de testes
Qualquer correção vinda de IA deve passar automaticamente por suites de testes unitários, de integração e de segurança, além de análise de qualidade de código.
3. Estabelecer critérios de aceitação claros
Definir que um patch só é aprovado se:
– Corrigir a vulnerabilidade;
– Não alterar comportamento essencial da aplicação sem justificativa;
– Não introduzir dependências desnecessárias ou complexidade excessiva.
4. Manter logs e rastreabilidade
Registrar quais partes do código foram alteradas com auxílio de IA, para facilitar auditorias futuras, revisões e compreensão de eventuais comportamentos inesperados.
5. Treinar a equipe para revisar código gerado por IA
Desenvolvedores precisam aprender a identificar padrões típicos de erro produzidos por modelos de linguagem, como validações superficiais, tratamentos incompletos de erros e suposições não documentadas.
Impactos estratégicos para CISOs e líderes de tecnologia
Para CISOs, CTOs e líderes de engenharia, o estudo é um lembrete de que automação em segurança não é sinônimo de delegar responsabilidade. A adoção de IA em processos críticos, como correção de vulnerabilidades, exige:
– Políticas claras sobre onde e como a IA pode ser utilizada;
– Avaliações de risco específicas para código gerado automaticamente;
– Inclusão desse tema em programas de governança de segurança;
– Monitoramento contínuo de incidentes relacionados a patches automatizados.
Além disso, a pesquisa reforça a necessidade de equilibrar velocidade e segurança. A pressão por corrigir falhas rapidamente não pode levar à adoção de patches não verificados apenas porque foram gerados por uma tecnologia “de ponta”.
O futuro dos patches gerados por IA
Apesar das limitações apontadas, os resultados não significam que a IA não tenha papel relevante no futuro da segurança de software. Ao contrário: à medida que os modelos evoluem e são combinados com ferramentas de teste automáticos mais sofisticados, é provável que:
– A taxa de sucesso de patches realmente corretos aumente;
– Modelos sejam ajustados especificamente para cenários de segurança;
– Ferramentas integrem geração de patch, teste, análise estática e revisão automática antes mesmo de chegar ao engenheiro humano.
Até lá, porém, o recado é direto: confiar cegamente em patches gerados por IA é arriscado. Eles podem ser um ponto de partida valioso, mas ainda estão longe de substituir o olhar crítico de especialistas. Em segurança, a aparência de correção pode ser tão perigosa quanto a vulnerabilidade original.