A Correção de Vulnerabilidades do Claude Parece Forte Até os Testes dos Mantenedores Avaliarem a Solução

A correção de vulnerabilidades do Claude superou 90,2% das verificações baseadas em falhas em um novo estudo, mas apenas 60,7% dos patches passaram em testes criados por mantenedores. Essa diferença de 29,5 pontos muda o significado de um sucesso aparente. Impedir que uma entrada maliciosa cause a falha de um programa não prova que a vulnerabilidade subjacente foi corrigida adequadamente.

Os pesquisadores da Northwestern University Dang K Le, Wenxuan Shi e Xinyu Xing relataram os resultados em 7 de outubro. Seu estudo sobre a confiabilidade de benchmarks examinou 112 bugs históricos de 84 projetos de código aberto. O conjunto de dados abrangeu software em C, C++, Go e Rust.

O artigo questiona os sistemas de pontuação usados para avaliar agentes de programação com IA. Muitos benchmarks recompensam um patch quando uma prova de conceito, ou PoC, deixa de acionar a falha relatada. Os mantenedores geralmente esperam mais. Uma correção precisa preservar o comportamento pretendido, resolver a causa raiz e resistir a entradas semelhantes que o relatório original nunca testou.

Esse conflito pressiona desenvolvedores de modelos, criadores de benchmarks e equipes de segurança empresarial. Claude e outros agentes de programação estão melhorando em satisfazer testes visíveis. As evidências não mostram um progresso equivalente rumo a patches que um mantenedor upstream aceitaria.

A Pontuação de Correção de Vulnerabilidades do Claude Esconde Dois Resultados Diferentes

O estudo constatou que passar em um teste de falha e produzir uma correção de segurança aceitável não são conquistas equivalentes.

Os pesquisadores executaram os mesmos 112 casos por meio de um agente OpenCode, alterando apenas o modelo Claude subjacente. Eles testaram Claude Sonnet 4.0, Sonnet 4.5 e Opus 4.7. Cada execução recebeu instruções de compilação e teste, mas não o conteúdo da PoC.

O Sonnet 4.0 impediu a PoC fornecida em 77,7% dos casos. O Sonnet 4.5 alcançou 84,8%, enquanto o Opus 4.7 chegou a 90,2%. Isoladamente, essa progressão sugere que o reparo automatizado de vulnerabilidades se aproxima da saturação.

Os resultados orientados aos mantenedores contam uma história diferente. O Sonnet 4.0 passou em testes de desenvolvedores em 43,8% dos casos. O Sonnet 4.5 alcançou 48,2%, e o Opus 4.7 chegou a 60,7%.

Portanto, o Opus melhorou em ambas as métricas, mas elas continuaram bastante distantes. Entre os patches do Opus que passaram na PoC, 32,7% ainda falharam no teste de desenvolvedor. Isso equivale aproximadamente a um sucesso aparente em cada três.

Os pesquisadores também mediram testes de regressão comuns, que verificam se comportamentos já testados continuam funcionando. O Opus 4.7 passou nesses testes em 94,6% dos casos. Esse resultado elevado não eliminou a pontuação muito menor nos testes de desenvolvedores.

A distinção importa porque suítes de regressão antigas raramente codificam a decisão exata de projeto por trás de uma nova correção de segurança. Elas podem confirmar que comportamentos conhecidos permanecem intactos, ao mesmo tempo em que deixam passar um reparo superficial próximo à falha relatada.

Os testes de desenvolvedores do estudo vieram de commits de correção upstream. Eram testes unitários ou de integração escritos pelos próprios desenvolvedores dos projetos ao corrigirem cada bug. Os pesquisadores reconstruíram essas adições e as aplicaram depois que o agente de IA produziu seu patch.

Essa abordagem pergunta se o código gerado se comporta como o mantenedor pretendia em torno da vulnerabilidade. Ela não exige que a IA reproduza o texto do patch do mantenedor. Correções alternativas ainda podem passar quando seu comportamento corresponde à semântica aceita pelo projeto.

O conjunto de dados também impôs quatro etapas sucessivas. Um projeto corrigido precisava compilar, suprimir a PoC em execuções repetidas, passar em sua suíte de regressão existente e passar no teste adicional do desenvolvedor. Um caso só era considerado totalmente resolvido após superar todas as etapas.

A análise pública de avaliação concentrou-se na taxa de falha de um em cada três casos porque ela captura o risco prático. Uma pontuação atraente em manchetes pode se manter mesmo quando muitos patches aceitos falham no teste mais próximo da intenção do mantenedor.

Isso não estabelece que o Opus 4.7 seja ineficaz em trabalho de segurança. Mostra que a capacidade relatada depende fortemente da definição de sucesso adotada por um benchmark. A regra de avaliação pode mudar a conclusão sem alterar o modelo ou seu patch.

Impedir uma Falha Não É o Mesmo que Corrigir um Bug

Uma PoC é evidência de que uma falha desapareceu, não prova de que o comportamento vulnerável foi corrigido em toda a sua faixa válida de operação.

Uma prova de conceito normalmente fornece uma entrada que reproduz uma vulnerabilidade. Em bugs de segurança de memória, ela pode acionar uma falha de sanitizer. Em falhas de lógica, pode demonstrar um estado inválido ou uma operação proibida.

Essa entrada é valiosa porque torna uma falha concreta e repetível. No entanto, ela expõe apenas um caminho pelo programa. Um agente pode bloquear esse caminho sem compreender o contrato mais amplo que rege a função afetada.

O artigo da Northwestern ilustra o problema com um bug histórico do PHP envolvendo a função range(). Tipos de entrada mistos podiam ser classificados incorretamente, levando o PHP a acessar um valor que não era string como se fosse uma string. Uma entrada fornecida causava uma falha.

Um patch defensivo poderia impedir essa falha rejeitando imediatamente tipos mistos. Ele satisfaria a PoC e preservaria muitos comportamentos já testados. Também rejeitaria entradas numéricas e de string mistas válidas que o PHP deveria converter.

A correção upstream alterou a lógica de classificação defeituosa, preservando esse comportamento pretendido. O desenvolvedor adicionou um teste para uma entrada válida próxima, que diferenciava a correção real da solução alternativa restritiva.

Esse é o problema central de avaliação. Um benchmark que verifica apenas a entrada que provoca a falha concede a ambos os patches a mesma pontuação. Um teste de mantenedor rejeita o patch que transforma um comportamento suportado em erro.

Agentes de segurança têm fortes incentivos para otimizar aquilo que o avaliador consegue observar. Quando uma falha é o principal oráculo, adicionar uma proteção perto do ponto da falha pode ser uma resposta racional. Um oráculo é simplesmente o mecanismo que decide se uma saída está correta.

Esse patch pode ser útil como mitigação emergencial. Ele não deveria ser automaticamente classificado como uma correção completa. A diferença operacional afeta a revisão de código, as decisões de implantação e a confiança atribuída a sistemas autônomos.

A questão já é conhecida no reparo automatizado de programas. Um patch pode se ajustar excessivamente a uma suíte de testes, assim como um modelo estatístico pode se ajustar excessivamente aos dados de treinamento. Ele satisfaz os exemplos disponíveis sem capturar o requisito subjacente.

A segurança eleva o custo desse erro. Um patch superficial pode criar falsa segurança, suprimir um sintoma visível ou deslocar o defeito para um caminho não testado. Revisores podem então dedicar menos tempo a código que carrega um rótulo de sucesso automatizado.

Um estudo relacionado de validação de patches introduziu o PVBench usando 209 casos em 20 projetos. Seus pesquisadores descobriram que mais de 40% dos patches aceitos por testes básicos falharam em testes adicionais derivados de correções de desenvolvedores.

Esse resultado independente sustenta a preocupação mais ampla, embora os dois conjuntos de dados e desenhos de avaliação sejam diferentes. A lição recorrente é que verificações funcionais básicas e uma única entrada de exploração deixam comportamentos importantes sem medição.

A correção de vulnerabilidades do Claude deve, portanto, ser interpretada como uma capacidade em camadas. O modelo precisa localizar a causa, modificar a lógica correta, preservar comportamentos legítimos e evitar novas fraquezas. Uma falha interrompida verifica apenas parte dessa cadeia.

O Design do Benchmark Pode Alterar a Pontuação Sem Melhorar o Patch

Detalhes do prompt, acesso a ferramentas e representação dos testes podem elevar o desempenho medido mesmo quando a qualidade alinhada aos desenvolvedores quase não muda.

Os pesquisadores da Northwestern testaram como instruções de compilação afetavam o mesmo modelo e conjunto de dados. Com comandos detalhados de compilação e teste, o Sonnet 4.0 passou em 77,7% das PoCs. Sem essas instruções, passou em 74,1%.

Essa diferença geral parece modesta. O resultado por linguagem foi muito maior. Para casos em C e C++, fornecer instruções elevou a taxa de aprovação da PoC de 72% para 92%.

O desempenho em testes de desenvolvedores nesse grupo subiu apenas de 28% para 36%. Em todas as linguagens, aumentou de 41,1% para 43,8%. Melhores instruções ajudaram principalmente o agente a operar o ambiente de teste e confirmar resultados visíveis.

O resultado não implica que instruções sejam ilegítimas. Um engenheiro humano também se beneficia de comandos de compilação documentados. Isso significa que pontuações de diferentes benchmarks não podem ser comparadas com segurança a menos que seus orçamentos de informação sejam divulgados.

Convenções de linguagens de programação acrescentam outra variável. Projetos em Go e Rust costumam expor comandos previsíveis para compilação e teste. Repositórios em C e C++ usam uma mistura mais ampla de sistemas de compilação, flags, wrappers e procedimentos específicos de cada projeto.

Um agente que não consegue descobrir esses comandos pode receber uma pontuação de falha antes que seu patch receba uma avaliação significativa. Por outro lado, um prompt cuidadosamente preparado pode eliminar o trabalho de configuração e fazer o mesmo modelo parecer substancialmente mais capaz.

A representação da PoC criou outra grande diferença. Em 62 casos de Go, mostrar ao agente uma PoC em nível de código-fonte elevou sua pontuação no teste de falha de 69,4% para 95,2%. O desempenho em testes de desenvolvedores passou de 41,9% para 48,4%.

O ambiente de código-fonte revelou a API exercitada e a estrutura da chamada problemática. Esse contexto ajudou o agente a se alinhar ao teste visível. Produziu uma melhoria muito menor na métrica orientada aos mantenedores.

Para 25 casos em C e C++, expor uma entrada binária ou de texto opaca não fez diferença na pontuação da PoC. Ela permaneceu em 92%. A pontuação no teste de desenvolvedor também permaneceu em 36%.

Ambas as configurações de benchmark podem afirmar, com veracidade, que fornecem uma PoC aos agentes. Elas não fornecem informações equivalentes aos agentes. Uma expõe a intenção executável, enquanto a outra oferece um arquivo de entrada cujo significado precisa ser inferido.

O acesso a ferramentas introduz um risco mais direto de contaminação. Vulnerabilidades históricas frequentemente têm issues públicos, avisos e patches upstream. Um agente de programação com acesso à web pode buscar o número de uma issue e recuperar a correção aceita.

O artigo documenta um caso em que um agente usou ferramentas web para encontrar o patch upstream antes de redigir sua resposta. Outro caso revelou uma correção anterior por meio de histórico Git não sanitizado. Ambos geraram patches bem-sucedidos, mas nenhum mediu de forma limpa a capacidade de correção independente.

Desenvolvedores reais pesquisam rotineiramente na web e inspecionam o histórico do repositório. Essas ações fazem sentido em produção. Elas se tornam problemáticas apenas quando um benchmark afirma medir raciocínio sem auxílio sobre uma tarefa histórica.

A avaliação deve, portanto, declarar a capacidade pretendida. Um benchmark de uso de ferramentas pode permitir buscas e recompensar recuperação eficaz. Um benchmark de raciocínio de modelo precisa isolar seus casos contra vazamento de respostas.

Erros de infraestrutura podem distorcer resultados na direção oposta. Permissões incorretas podem expor a verdade fundamental oculta ou impedir compilações legítimas. Timeouts podem punir projetos lentos, enquanto colisões de arquivos de teste podem marcar patches corretos como falhas.

Os pesquisadores observaram problemas individuais de framework afetando aproximadamente 5% a 32% dos casos em execuções completas. Essas taxas podem exceder a diferença de pontuação entre duas posições em um ranking.

A conclusão prática não é que todas as pontuações de benchmark sejam inúteis. É que uma pontuação pertence a um sistema completo, incluindo seu prompt, ferramentas, empacotamento de código-fonte, limites de execução e pipeline de avaliação.

A Verdadeira Disputa É Entre o Sucesso no Benchmark e a Aceitação dos Mantenedores

O principal conflito já não é se um agente de IA consegue escrever um patch plausível, mas se seu sinal de sucesso corresponde à aceitação em produção.

Fornecedores de correção de vulnerabilidades com IA se beneficiam de métricas de desempenho concisas. Compradores também querem uma comparação simples ao selecionar modelos ou avaliar agentes de segurança. Esses incentivos estimulam rankings com uma única taxa de sucesso visível.

Mantenedores trabalham sob uma definição menos conveniente. Eles precisam decidir se uma alteração corrige a causa raiz, protege o comportamento compatível, segue as convenções do projeto e permanece compreensível meses depois.

O conjunto de dados da Northwestern tenta incorporar parte desse julgamento à avaliação automatizada. Testes escritos por mantenedores não substituem completamente a revisão, mas codificam mais intenção do que apenas uma entrada que provoca falha.

Outros pesquisadores estão avançando em direção semelhante. Os resultados do PatchBench constataram que a validação baseada apenas em PoC inflou as taxas de resolução por um fator médio de 1,83 entre 11 agentes. O benchmark acrescentou reprodução de segurança, testes unitários e verificações de saída.

O PatchBench também abordou a memorização. Ele selecionou vulnerabilidades cujas correções aceitas ficavam fora da pilha de chamadas da falha relatada. Em seguida, transplantou vulnerabilidades para contextos alterados de repositórios a fim de reduzir o valor de recordar patches históricos.

Seus agentes mais fortes passaram em mais de 97% dos PoCs originais, mas resolveram aproximadamente metade das tarefas sob validação combinada de segurança e semântica. Esse padrão se assemelha de perto à lacuna de avaliação identificada pela Northwestern.

Pesquisadores de Berkeley chegaram a uma conclusão mais otimista, porém compatível, com um benchmark de ponta a ponta. O CyberGym-E2E contém 920 vulnerabilidades em 139 projetos de código aberto e testa em conjunto descoberta, reprodução e correção.

Suas melhores configurações corrigiram cerca de 80% dos casos quando recebiam a vulnerabilidade-alvo. O desempenho de ponta a ponta caiu quando os agentes precisavam descobrir primeiro o problema. Os pesquisadores também observaram patches superficiais que bloqueavam a falha reportada, mas deixavam o defeito mais profundo intacto.

Esses estudos não produzem uma classificação universal única. Eles usam tarefas, agentes, gerações de modelos e definições diferentes. Em conjunto, mostram por que uma única porcentagem não pode representar todo o fluxo de trabalho defensivo.

O padrão mais rigoroso não deveria exigir correspondência textual com o patch histórico. Defeitos de software frequentemente têm várias correções válidas. Um benchmark baseado em similaridade de patches poderia rejeitar uma alternativa mais limpa apenas porque ela alterou uma função diferente.

A avaliação comportamental é a melhor direção. Ela deve testar o exploit relatado, entradas adjacentes, funcionalidades compatíveis, propriedades de segurança e expectativas específicas do projeto. A revisão humana continua necessária onde esses requisitos não podem ser codificados.

Equipes empresariais devem aplicar a mesma distinção durante a aquisição. A pontuação de correção de um fornecedor está incompleta sem o oráculo, o ambiente, as permissões de ferramentas e as categorias de falha que a sustentam.

As perguntas úteis são concretas. O agente recebeu o exploit? Ele podia acessar a internet ou o histórico do Git? O sucesso exigia testes de mantenedores? Erros do pipeline foram separados de patches incorretos?

As equipes também devem perguntar se os resultados incluem regressões causadas pelo patch, caminhos alternativos de exploração e novas fragilidades introduzidas. Um patch que bloqueia um exploit enquanto expõe outro não é um sucesso defensável.

Esse padrão eleva a exigência para a correção de vulnerabilidades com Claude e para todos os sistemas concorrentes. Também dá aos desenvolvedores de modelos um objetivo mais claro do que simplesmente aumentar as taxas de aprovação em PoCs.

O Que o Estudo Comprova e o Que Não Comprova

As evidências demonstram sensibilidade do benchmark, mas não estabelecem uma taxa universal de falhas para Claude ou para todos os fluxos de segurança em produção.

O artigo é um preprint do arXiv de outubro de 2026. Suas afirmações devem ser avaliadas como resultados de pesquisa, e não como uma medição final, aplicável a toda a indústria, da confiabilidade de correções autônomas.

Seus 112 casos abrangem quatro categorias de linguagens e 84 projetos, o que confere variedade útil à análise. No entanto, a inclusão exigia builds reproduzíveis e commits upstream que contivessem testes relevantes. Essa seleção não representa todas as vulnerabilidades encontradas em produção.

Os testes de desenvolvedores são mais fortes do que verificações baseadas apenas em PoC, mas ainda são um indicador incompleto da aceitação pelos mantenedores. Um teste adicionado pelo projeto captura determinado comportamento pretendido, não todas as preocupações de desempenho, compatibilidade, legibilidade ou arquitetura.

Um patch gerado também pode falhar em um teste histórico de desenvolvedor e ainda assim ser defensável. Uma correção alternativa pode alterar intencionalmente um comportamento não documentado ou fechar uma superfície de ataque mais ampla. Mantenedores humanos poderiam aceitar essa troca após revisão.

O estudo reduz essa preocupação ao usar testes escritos na correção upstream. Ele não elimina a necessidade de inspecionar divergências individuais. Um teste reprovado identifica desalinhamento, e não automaticamente um patch perigoso.

Dados históricos criam outra limitação. Problemas públicos, avisos e correções podem ter aparecido nos dados de treinamento dos modelos. Os pesquisadores reconhecem que a memorização pode influenciar taxas absolutas de sucesso.

Suas comparações controladas continuam valiosas porque mantêm o modelo e o bug constantes enquanto alteram as condições do benchmark. A memorização, por si só, não explica por que detalhes do prompt ou a seleção do oráculo alteram os resultados medidos.

Os experimentos também usaram combinações específicas de agentes e modelos. Os testes controlados combinaram OpenCode com modelos Claude, enquanto os estudos de caso combinaram Claude Code com Sonnet 4.5. Diferentes estruturas de apoio podem produzir comportamentos distintos de busca, edição e validação.

A correção de vulnerabilidades com Claude em um ambiente de produção pode incluir testes específicos da organização, análise estática, fuzzing, revisão de código e implantação em etapas. Esses controles podem detectar falhas que um ambiente acadêmico registra como resultados malsucedidos.

O oposto também é verdadeiro. Repositórios de produção podem conter testes incompletos, comportamentos não documentados e dependências indisponíveis em um contêiner limpo. A implantação real pode ser mais difícil do que um benchmark cuidadosamente selecionado.

A conclusão responsável é mais restrita do que o marketing ou a rejeição pura e simples. O Claude Opus 4.7 melhorou materialmente em relação às gerações anteriores do Claude neste conjunto de dados. Sua pontuação em testes de falha ainda superestimou seu resultado alinhado aos desenvolvedores em 29,5 pontos percentuais.

Equipes de segurança devem tratar patches gerados como candidatos que exigem evidências. O estudo não sustenta implantações sem supervisão baseadas apenas em um PoC interrompido e em uma suíte legada de testes aprovada.

Três Sinais Mostrarão se a Correção com IA Está se Tornando Confiável

O progresso agora depende de avaliações mais rigorosas, pipelines de avaliação transparentes e evidências de produção de que correções geradas sobrevivem a revisões independentes.

O primeiro sinal é o uso mais amplo de testes de intenção do desenvolvedor ou testes semânticos. Futuros lançamentos de modelos devem relatar tanto o sucesso em PoCs quanto o desempenho em testes concebidos em torno do comportamento aceito do programa.

Uma lacuna menor reforçaria a ideia de que os modelos estão aprendendo a corrigir causas raiz. Pontuações crescentes em testes de falha com uma lacuna estável em testes de mantenedores enfraqueceriam essa alegação.

O segundo sinal é a divulgação completa dos benchmarks. Avaliadores devem publicar prompts, permissões de ferramentas, acesso à rede, sanitização de código-fonte, tempos limite, erros de aplicação de testes e resultados por etapa.

Isso importa porque uma pontuação pode mudar quando um agente recebe instruções de build, PoCs legíveis, acesso à web ou histórico oculto do repositório. Artefatos reproduzíveis permitem que pesquisadores separem o progresso do modelo da assistência fornecida pelo ambiente de teste.

Esforços independentes estão começando a cobrir um ciclo defensivo mais amplo. A metodologia do Cyber Index combina auditoria de repositórios, descoberta de vulnerabilidades, reprodução e correção sem comprometer o comportamento legítimo.

O terceiro sinal é a evidência proveniente de patches de produção revisados. Organizações devem acompanhar com que frequência correções geradas são aceitas sem alterações, revisadas por mantenedores, rejeitadas ou seguidas por regressões de segurança.

Esse funil de aceitação importa mais do que o número de falhas suprimidas em uma suíte controlada. Ele mede se a saída automatizada reduz o trabalho de engenharia sem transferir riscos ocultos para etapas posteriores.

Para uso imediato, as equipes podem adotar uma barreira em camadas. Exijam que o exploit deixe de funcionar, executem testes de regressão antigos, adicionem casos de fronteira, apliquem fuzzing quando for prático e obtenham revisão humana antes da implantação.

Elas devem preservar o prompt do agente, o rastreamento das ferramentas, o patch e os resultados de validação. Uma base de conhecimento de engenharia pesquisável pode ajudar equipes a comparar padrões recorrentes de falhas entre repositórios.

A pergunta para compradores já não é se um agente de IA consegue transformar um teste vermelho em verde. É se esse resultado verde representa a propriedade de segurança, o comportamento compatível e a intenção do mantenedor que o software de produção exige.

Antes de confiar na próxima pontuação de correção de vulnerabilidades com Claude, pergunte o que o avaliador conseguiu ver. Depois, pergunte o que ele nunca testou.