Um novo estudo da Universidade de Maryland questiona o significado de alguns resultados elevados obtidos por agentes de IA na correção de vulnerabilidades. O benchmark PatchBench não se limita a confirmar que a entrada que fazia o programa falhar deixou de provocar o mesmo erro. Procura saber se a causa da vulnerabilidade foi realmente eliminada e se o software continua a comportar-se corretamente em situações legítimas.
O preprint, submetido ao arXiv a 3 de setembro, avalia 11 agentes em tarefas de correção de vulnerabilidades em C e C++. Segundo os autores, validar apenas uma prova de conceito faz o desempenho parecer, em média, 1,83 vezes superior. Os três melhores agentes ultrapassam 97% nessa verificação inicial, mas ficam perto de metade das tarefas quando o benchmark acrescenta testes de segurança mais amplos e validação do comportamento. Para uma equipa de segurança, esta diferença é mais relevante do que a posição numa tabela: deixar de reproduzir um crash não demonstra, por si só, que a vulnerabilidade foi corrigida.
PatchBench torna mais exigente a definição de correção válida
O benchmark reúne 213 tarefas, distribuídas por 16 classes CWE e 32 projetos reais. A sua construção tenta eliminar dois atalhos que podem fazer os agentes parecer mais eficazes do que são.
O primeiro é a possível memorização de correções antigas. Os investigadores transplantam vulnerabilidades históricas para versões mais recentes dos repositórios e alteram o código em torno da zona onde a correção é aplicada. Assim, reduzem a possibilidade de um modelo repetir uma solução de um programador que possa ter aparecido nos dados de treino. Num estudo separado sobre o SEC-bench, os autores estimam que cerca de 25% das correções produzidas por agentes com acesso ao repositório são muito semelhantes às correções históricas. O artigo não apresenta essa semelhança como prova definitiva de contaminação dos dados de treino, mas considera-a um risco sério para a validade da avaliação.
O segundo atalho é corrigir apenas o local onde o programa falha. O PatchBench escolhe vulnerabilidades cuja correção histórica se encontra fora da pilha de chamadas associada ao crash. Desta forma, o agente tem de encontrar a origem do problema em vez de acrescentar apenas uma proteção no ponto assinalado pela ferramenta de diagnóstico.
A validação também é feita por etapas. Novas entradas obtidas através de fuzzing verificam se outros caminhos continuam a explorar a mesma falha. Entradas benignas, verificações de regressão, o estado de saída do programa e testes unitários servem para confirmar que a correção não altera indevidamente o funcionamento esperado.
Evitar um crash não é o mesmo que eliminar a vulnerabilidade
O resultado mais importante não é qual dos agentes ficou em primeiro lugar, mas a queda de desempenho quando o critério de aceitação se aproxima mais de uma validação de segurança real.
De acordo com o artigo, os três melhores agentes ultrapassam 97% quando são avaliados apenas com a prova de conceito original. Com várias entradas de segurança, passam para 75% a 82%. Quando a validação semântica é acrescentada, os melhores resultados ficam aproximadamente em metade do conjunto. Há ainda 67 tarefas que nenhum dos 11 agentes consegue resolver.
O exemplo apresentado pelos investigadores ajuda a perceber a diferença. Uma falha pode nascer numa parte do programa e só causar um crash mais tarde, noutro componente. Um agente pode colocar uma verificação no local do crash e impedir que a entrada fornecida volte a provocar o erro, mantendo intacto o estado incorreto que surgiu antes. O teste simples passa, mas outros caminhos de exploração ou comportamentos errados podem continuar presentes.
A decisão de aceitar a correção deve ser independente do agente
A principal conclusão da Aipolix é prática: num processo automatizado de remediação, a geração da correção e a decisão de a aceitar não devem ficar na mesma etapa.
O agente pode propor a alteração, mas a passagem para produção deve depender de uma verificação independente que responda, pelo menos, a três perguntas. A correção elimina outros caminhos para a mesma vulnerabilidade, além do exemplo inicial? Mantém o comportamento legítimo e os testes existentes? Atua na causa do problema em vez de esconder apenas o ponto onde o erro se manifesta?
Esta separação altera a fronteira de confiança num processo de segurança com agentes. Se o mesmo agente escreve a correção, volta a executar uma única prova de conceito e declara o problema resolvido, o processo continua estruturalmente frágil. Fuzzing independente, testes de regressão e comparação de comportamento devem fazer parte das condições de aceitação.
O PatchBench também chama a atenção para um problema dos próprios benchmarks. Quando se reutilizam vulnerabilidades públicas e antigas, um resultado elevado pode combinar raciocínio genuíno com padrões de correção já conhecidos pelo modelo. Mover a vulnerabilidade para um novo contexto e alterar o código em torno da correção não elimina totalmente esse risco, mas dificulta a simples reprodução de uma solução histórica.
O resultado é relevante, mas a reprodução ainda tem uma falha
Este trabalho é a primeira versão de um preprint no arXiv e ainda não existe uma reprodução independente dos resultados. As experiências concentram-se em C e C++, pelo que não é correto generalizar automaticamente as conclusões para todas as linguagens, tipos de falha ou repositórios empresariais.
Há também uma inconsistência na disponibilização dos artefactos. O artigo afirma que o código e o benchmark foram publicados em github.com/ai-sec-lab/PatchBench. Quando a Aipolix verificou esse endereço a 4 de setembro, a página devolvia 404 e o repositório não podia ser inspecionado. Isto não invalida os resultados descritos no artigo, mas impede, neste momento, que uma equipa externa confirme o artefacto anunciado através do endereço indicado pelos autores.
A conclusão deve, por isso, ser mais limitada do que afirmar que os agentes não conseguem corrigir vulnerabilidades. O que o PatchBench mostra é que uma validação demasiado estreita pode exagerar bastante a qualidade real da correção. Para equipas que já estão a experimentar remediação autónoma, a regra útil é clara: uma correção gerada por um agente deve continuar a ser tratada como proposta até passar verificações independentes de segurança e de comportamento.