TL;DR
- O GPT-5.6 obteve a pontuação mais elevada em termos de recall, atingindo um máximo de 23/26, à frente do grok-4.5 (20), dos modelos Claude Opus (15 a 18) e de todos os outros que testámos. Isso significa que consegue redescobrir 88,5% das CVEs.
- A opção mais cara não é necessária. As variantes mais económicas do GPT-5 .6 ficam a apenas um ou dois resultados do seu modelo topo de gama, por uma fração do custo, e a combinação de algumas execuções de um modelo de gama média rivaliza com uma única execução do modelo topo de gama.
- As execuções do modelo são inconsistentes, mas a agregação de resultados significa que obtêm melhores resultados. Qualquer execução isolada pode deixar escapar erros que seriam detetados noutra; executar um modelo várias vezes e agregar os resultados (pass@3) supera de forma fiável uma única execução de um modelo mais potente e mais caro.
- O «Open Weight» está a ganhar terreno rapidamente. O GLM-5 .2 já redescobre 59% do conjunto (16/26), situando-se a meio da tabela entre os modelos proprietários.
Atualmente, cada lançamento de um modelo de ponta vem acompanhado da mesma promessa em matéria de cibersegurança: que deteta vulnerabilidades. Mas será que funciona com um bug real num repositório real, ou apenas com um exemplo cuidadosamente selecionado? De entre a dúzia de modelos que se pode escolher, em qual vale a pena confiar para a revisão de código? E, uma vez que os modelos mais avançados custam dez vezes mais — ou mais — por execução do que os mais baratos, o que é que esse gasto adicional realmente lhe proporciona em termos de bugs detetados?
É fácil classificar os modelos com base na sua capacidade bruta e considerar o mais caro como o vencedor, mas a questão mais importante é saber se o preço justifica o investimento. Por isso, testámos 13 dos modelos entre os quais as equipas estão a escolher atualmente, confrontando-os com 26 vulnerabilidades conhecidas da base de dados de alertas do GitHub. Estas abrangem uma variedade de linguagens e tipos de projetos. Medimos dois aspetos: quantos erros cada modelo detetou e quanto custou detetá-los.
Como funciona o índice de referência
Selecionámos 26 vulnerabilidades da base de dados de alertas do GitHub — uma amostra aleatória que abrange várias linguagens de programação e tipos de projetos, desde injeção de SQL num framework web até um RCE por deserialização num kit de ferramentas de ML — e pedimos a cada modelo que as redescobrisse, um repositório de cada vez, no âmbito da mesma análise de código com IA que utilizamos em produção. Em vez de uma janela de chat, trata-se de um modelo com ferramentas reais que navega pelo repositório e analisa o código da mesma forma que um auditor o faria.
O «harness» é o que transforma um modelo de linguagem num auditor. Um assistente de programação de uso geral é concebido para uma função diferente: receber uma tarefa e produzir código funcional. Se o direcionarmos para um repositório e perguntarmos se este é seguro, ele comporta-se como um programador que analisa rapidamente em busca de algo manifestamente errado e pára assim que encontra algo plausível. análise de código com IA é concebida de forma diferente. Ela explora a base de código à procura de pontos de entrada potenciais, investiga cada fluxo suspeito em profundidade e, em seguida, faz uma triagem dos resultados para que apenas as vulnerabilidades reais sejam identificadas.
Como sabíamos onde cada vulnerabilidade se encontrava, direcionámos cada agente investigador diretamente para o trecho de código vulnerável. Dessa forma, uma falha reflete o raciocínio, em vez de um desperdício de orçamento ao explorar a parte errada da base de código. O modelo ainda tem de compreender o fluxo, avaliar a explorabilidade e comunicá-la corretamente. As instruções foram mantidas curtas e independentes do modelo, para que nenhum fornecedor fosse favorecido pela formulação do texto.
Executámos cada modelo três vezes e agrupámos os resultados. Um CVE é considerado «detetado» se o modelo o identificar em qualquer execução (pass@3).
Escolhemos uma variedade dos modelos mais recentes de diferentes fornecedores:
- OpenAI: gpt-5.4-nano, gpt-5.4-mini, gpt-5.5 e a série gpt-5.6 (luna / terra / sol)
- Anthropic: claude-haiku-4-5, claude-opus-4-7, claude-opus-4-8
- xAI: grok-4.5
- Google: gemini-3.1-pro, gemini-3.5-flash
- Peso aberto: glm-5.2
Resultados por gravidade e vulnerabilidade
Todos os modelos identificaram ambas as vulnerabilidades CVE críticas (uma RCE por deserialização e um XSS armazenado). A verdadeira diferença torna-se evidente nas vulnerabilidades de gravidade elevada e média.
CVE mais difíceis e mais fáceis
Os dois erros críticos e várias falhas evidentes de injeção e controlo de acesso foram detetados por todos os modelos. Um pequeno número de cadeias específicas conseguiu contornar quase todas elas.
As vulnerabilidades CVE detetadas por todos os modelos seguem o mesmo padrão: entradas controladas pelo atacante que conduzem a uma operação perigosa bem conhecida através de um fluxo curto e local, como uma chamada de deserialização, a execução de um shell, um sink HTML ou uma verificação de assinatura defeituosa. Trata-se de reconhecimento de padrões, e esta questão foi resolvida de forma eficaz. Tanto os modelos mais económicos como os topo de gama obtêm uma pontuação de 13/13, sem qualquer diferença de desempenho.
A verdadeira fronteira — e onde a capacidade dos modelos se distingue realmente — reside na capacidade de raciocinar sobre as verificações que não existem e de seguir cadeias complexas que nenhuma linha isolada revela. O caso mais evidente é a «SQL Injection-1» no nosso conjunto de dados, uma injeção indireta através de um alias de coluna que o ORM nunca escapa. Apenas o GPT-5.5 e os modelos GPT-5.6 mais potentes (sol e terra) conseguiram identificá-la.
O que a diferença entre a média e a união nos revela
O valor mais útil neste teste de desempenho é a distância entre a execução média de um modelo e a união das suas execuções. Como cada passagem revela um subconjunto diferente de erros, a sua agregação (pass@3) permite recuperar uma quantidade surpreendente:
Veja o gpt-5.4-nano: nenhuma execução isolada ultrapassa os 14, mas três execuções combinadas atingem os 18, um aumento de quatro CVE, porque cada passagem revela erros diferentes. O claude-haiku-4-5 é o caso mais marcante de variância, obtendo 7 numa execução e 13 noutra, com o mesmo modelo e na mesma tarefa.
A lição a reter aqui é que não é necessário optar logo pelo modelo mais caro. Três execuções do gpt-5.4-nano custam cerca de 170 dólares e atingem 18/26, o mesmo resultado médio que uma única execução de um modelo topo de gama como o gpt-5.6-terra alcança por si só, por uma fração do preço. Três execuções do gpt-5.4-mini (cerca de 460 dólares) atingem 20. Repetir um modelo sólido de gama média supera uma única execução de um modelo topo de gama com muito mais frequência do que a diferença de preço sugere.
Vale a pena o raciocínio superior?
Executámos os modelos em questão em dois níveis de raciocínio: o nível predefinido «alto» e o nível mais elevado disponível («xhigh» para os modelos GPT-5.4/5.5 e Claude, e «max» para os modelos GPT-5.6, grok-4.5 e glm-5.2). Todos os valores correspondem a uniões de pass@3, pelo que são diretamente comparáveis.
Os vencedores claros são o gpt-5.5 (+3 a 1,5 vezes o custo) e o glm-5.2 (+3 a 1,3 vezes). O claude-opus-4-8 ganha +2, mas custa o dobro. Em todos os outros casos, o nível superior obtém um resultado ou nenhum, e no caso do gpt-5.6-luna e do gpt-5.4-nano ficou um ponto abaixo, dentro da variação normal entre execuções. O gpt-5.6-terra é o caso mais evidente de rendimentos decrescentes: 2,2 vezes o custo para os mesmos 23.
Os modelos Gemini não têm nenhuma configuração superior a «alta», pelo que foram excluídos desta comparação.
Conclusão
Basta aplicar um modelo do Frontier a uma base de código, dentro de um ambiente de teste concebido para o efeito, e este volta a detetar a maioria das vulnerabilidades conhecidas. Os erros com um ponto de destino perigoso óbvio são resolvidos. Os que ainda separam os modelos não têm um ponto de destino para onde apontar. Uma verificação de autorização em falta ou uma injeção à qual só se consegue chegar seguindo uma longa cadeia obscura ao longo de vários ficheiros.
O nível mais caro raramente justifica o seu preço. Executar um modelo mais barato algumas vezes e agregar os resultados permite obter mais, por menos, do que uma única execução de um modelo de topo, e essa vantagem só aumenta à medida que os modelos se tornam mais baratos e mais potentes. O harness continua a ser o que determina, em primeiro lugar, se esse raciocínio é direcionado para a parte certa da base de código.
