O agente encontrou uma vulnerabilidade, gerou um patch e o código compilou. A esteira ficou verde. Para uma empresa pressionada por velocidade, esse resultado parece suficiente para liberar a mudança. Não é. Compilar demonstra apenas que um compilador aceitou aquela representação, naquele ambiente. Não demonstra que a vulnerabilidade desapareceu, que a função preservou seu contrato ou que o sistema continua seguro em produção.
O que o estudo realmente mediu
O preprint Metrics Failure in LLM-Based Code Vulnerability Repair selecionou 203 funções C/C++ do Big-Vul, distribuídas por sete categorias CWE, com 29 funções em cada categoria. Os autores avaliaram três modelos de código de pesos abertos, de 350 milhões a 6,7 bilhões de parâmetros, em três estratégias de prompt e cinco amostras por combinação. Isso produz 3.045 patches por modelo e 9.135 gerações no total [1].
Além da comparação principal, o estudo conduziu cinco experimentos controlados para perguntar se a taxa de compilação e o CodeBLEU respondiam àquilo que supostamente mediam. O repositório disponibiliza o harness de compilação, a implementação da métrica proposta, os prompts, os identificadores das funções e scripts para reproduzir tabelas e figuras [2]. Disponibilizar artefatos melhora a auditabilidade; ainda não equivale a uma replicação independente.
Quando a métrica mede o ambiente, não o reparo
Os três modelos obtiveram taxas de compilação entre aproximadamente 3% e 5,5%. Ao investigar as falhas, os autores atribuíram cerca de 64% delas a condições do conjunto de dados ou do ambiente de avaliação, como ausência de contexto do projeto e configuração da toolchain — não diretamente à capacidade do modelo. Em uma classe de falha, o pré-processamento do Big-Vul havia removido tipos de retorno em 96% a 100% dos casos examinados [1].
O teste mais direto manteve os patches idênticos e mudou apenas o padrão de linguagem usado pelo compilador. A taxa de compilação variou de 1,8 a 2,7 vezes, sem qualquer alteração no código gerado ou na vulnerabilidade. Quando uma configuração externa muda tanto o placar, o número precisa vir acompanhado do compilador, flags, dependências, stubs e contexto utilizados [1].
A não correção que pode pontuar melhor
A alternativa baseada em similaridade também falhou no teste de significado. Quando o CodeBLEU foi calculado sobre a função inteira, copiar a função vulnerável sem qualquer alteração superou todos os modelos. O contexto que permaneceu igual dominou a pontuação, embora a vulnerabilidade também permanecesse [1].
O estudo também observou que otimizar a taxa de compilação podia recompensar exclusões, placeholders e stubs que compilavam sem reparar o comportamento. A métrica experimental diff_F1 compara a região editada e evita dar crédito ao simples no-op, mas os próprios autores mostram que ela ainda pode pontuar deleções inadequadas. Por isso, apresentam-na como uma triagem complementar, não como medida de qualidade ou segurança [1].
O que muda na esteira de desenvolvimento com IA
- Registre modelo, versão, prompt, contexto, ferramentas, patch, compilador, flags e dependências para tornar a avaliação reproduzível.
- Inclua baselines de no-op e de patches degenerados. Se copiar, apagar ou neutralizar código pontua bem, a métrica não pode ser gate de qualidade.
- Avalie o diff antes do arquivo inteiro: intenção da mudança, arquivos tocados, contrato alterado e escopo inesperado.
- Execute testes funcionais, regressão e testes específicos da vulnerabilidade no contexto real do projeto, não apenas em uma função isolada.
- Use análise estática, dinâmica, fuzzing e revisão humana de forma complementar; nenhuma ferramenta isolada é um oráculo de segurança.
- Separe sugestão do agente, aprovação do responsável e autorização para merge ou deploy em mudanças de alto impacto.
- Monitore a produção e mantenha rollback. Um patch correto no teste ainda pode interagir com configuração, estado e tráfego não representados.
O NIST SSDF trata desenvolvimento seguro como um conjunto de resultados organizacionais, técnicos e operacionais, não como um selo de uma ferramenta [4]. Suas diretrizes de verificação recomendam combinar análise, testes automatizados, casos estruturais, testes históricos, fuzzing e técnicas adequadas ao risco [5]. O estudo recente não cria esse princípio; ele mostra por que a programação assistida por IA torna urgente aplicá-lo com rastreabilidade.
Limites, contrapontos e conflitos
- O trabalho é um preprint v1 submetido ao arXiv em 22/09/2026. Não foi localizada, no corte desta análise, revisão por pares publicada nem replicação independente [1].
- O experimento cobre três modelos de 350M a 6,7B, uma amostra do Big-Vul, sete CWEs e funções C/C++ isoladas. Não caracteriza modelos maiores, agentes em repositórios completos ou todas as classes de vulnerabilidade [1].
- Os autores não fizeram validação por execução ou exploit e não compararam diff_F1 com julgamento humano. Compilar não é corrigir; diff_F1 também não é um oráculo [1].
- O estudo PrimeVul já havia identificado problemas de qualidade, duplicação e realismo em datasets de vulnerabilidades, oferecendo corroboração para a preocupação com o benchmark — não uma replicação deste experimento de reparo [3].
- Não foi localizada declaração de financiamento ou conflito comercial no paper. Ausência de declaração encontrada não prova inexistência de conflito.
- Modelos, datasets e ferramentas citados são objetos de avaliação. O estudo não atribui negligência, dano ou falha de produto a seus mantenedores.
Um plano de 30 dias para trocar placar por evidência
- Semana 1: inventarie onde IA gera, revisa ou corrige código e quais gates hoje autorizam merge e deploy.
- Semana 2: adicione baselines negativos, capture toolchain e crie testes que falhem com a vulnerabilidade original.
- Semana 3: rode os mesmos patches em ambiente reproduzível e no contexto do repositório, registrando divergências.
- Semana 4: defina níveis de risco, revisão obrigatória, evidência mínima, rollback e acompanhamento de falhas em produção.
A IA reduz o custo de produzir uma tentativa de correção. Isso aumenta — não diminui — a importância de saber o que conta como prova. O ganho de velocidade aparece quando a empresa automatiza geração e evidência; se automatizar apenas a geração, a dívida retorna no momento mais caro: revisão, incidente ou produção.
Nota editorial e de responsabilidade
Fatos, números, versões e condições experimentais estão ligados às fontes diretas. Interpretações, controles propostos e implicações para empresas são pontos de vista pessoais e profissionais do autor, não fatos universais. Este conteúdo é informativo e não substitui avaliação técnica, jurídica ou de segurança. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, autoral e autorização de publicação foram confirmadas por Fernando Parreiras em 23/09/2026, sem revisão humana independente adicional.