Atualização, 19 de julho: Desde que publicamos este blog, o Kimi K3 foi lançado. Nós o benchmarkamos também, e ele empatou com o GPT-5.6 na maior pontuação, ficando apenas um pouco atrás nas capacidades gerais. Veja a seção Kimi K3 no final para mais informações.
TL;DR
- O GPT-5.6 obtém a maior pontuação de recall, atingindo 23/26, à frente do grok-4.5 (20), dos modelos Claude Opus (15 a 18) e de todos os outros que testamos. Isso significa que ele pode redescobrir 88.5% das CVEs.
- A opção mais cara não é necessária. As variantes mais baratas do GPT-5.6 chegam a uma ou duas descobertas de sua versão flagship por uma fração do custo, e agrupar algumas execuções de um modelo de nível médio rivaliza com uma única passagem de um flagship.
- As execuções do modelo são inconsistentes, mas o pooling significa que elas vencem. Qualquer execução única perde bugs que pegaria em outra; executar um modelo algumas vezes e agrupar os resultados (pass@3) supera de forma confiável uma única passagem de um modelo mais forte e caro.
- O peso aberto está alcançando rapidamente. O GLM-5.2 já redescobre 59% do conjunto (16/26), no meio do pacote entre os modelos proprietários.
Todo lançamento de modelo de fronteira agora vem com a mesma afirmação de cibersegurança: ele encontra vulnerabilidades. Mas funciona em um bug real em um repositório real, ou apenas em um exemplo selecionado? Dos doze modelos que você poderia escolher, qual vale a pena confiar para revisão de código? E como os modelos mais fortes custam dez vezes ou mais por execução do que os mais baratos, o que esse gasto extra realmente compra em bugs encontrados?
É fácil classificar modelos pela capacidade bruta e chamar o mais caro de vencedor, mas a questão mais importante é se o preço vale a pena. Então, executamos 13 dos modelos que as equipes estão escolhendo hoje contra 26 vulnerabilidades conhecidas do banco de dados de avisos do GitHub. Eles abrangem uma variedade de linguagens e tipos de projeto. Medimos duas coisas: quantos bugs cada modelo encontrou e quanto custou para encontrá-los.
Como o benchmark funciona
Pegamos 26 vulnerabilidades do banco de dados de avisos do GitHub, uma distribuição aleatória entre linguagens e tipos de projeto, desde injeção SQL em um framework web até um RCE de desserialização em um toolkit de ML, e pedimos a cada modelo para redescobertá-las um repositório por vez dentro do mesmo harness de análise de código com IA que executamos em produção. Em vez de uma janela de chat, é um modelo com ferramentas reais que navega pelo repositório e raciocina sobre o código da mesma forma que um auditor.
O harness é o que transforma um modelo de linguagem em um auditor. Um assistente de codificação de propósito geral é construído para um trabalho diferente, que é pegar uma tarefa e produzir código funcional. Aponte-o para um repositório e pergunte se ele é seguro, e ele se comporta como um desenvolvedor procurando algo obviamente quebrado, e então para assim que encontra algo plausível. A análise de código com IA é construída de forma diferente. Ela vasculha a base de código em busca de pontos de entrada candidatos, investiga cada fluxo suspeito em profundidade e, em seguida, tria o que retorna para que apenas vulnerabilidades reais sobrevivam.
Como sabíamos onde cada vulnerabilidade residia, direcionamos cada agente investigador diretamente para o trecho de código vulnerável. Dessa forma, uma falha reflete o raciocínio, e não o orçamento desperdiçado vagando pelo canto errado da base de código. O modelo ainda precisa entender o fluxo, julgar a explorabilidade e reportá-la corretamente. Os prompts foram mantidos curtos e agnósticos ao modelo para que nenhum fornecedor seja beneficiado pela formulação.
Executamos cada modelo três vezes e agrupamos os resultados. Uma CVE é considerada 'encontrada' se o modelo a 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
- Open weight: glm-5.2
Resultados por severidade e vulnerabilidade
Todos os modelos redescobriram ambas as CVEs críticas (uma RCE de desserialização e um XSS armazenado). A verdadeira distinção aparece nas descobertas de severidade alta e média.
CVEs mais difíceis e mais fáceis
Os dois bugs críticos e várias falhas claras de injeção/controle de acesso foram encontrados por todos os modelos. Um punhado de cadeias específicas derrotou quase todos eles.
As CVEs que todos os modelos encontram compartilham o mesmo padrão: entradas controladas por atacantes atingindo uma operação perigosa bem conhecida através de um fluxo curto e local, como uma chamada de desserialização, uma execução de shell, um sink HTML ou uma verificação de assinatura quebrada. Isso é reconhecimento de padrões e está efetivamente resolvido. Modelos baratos e carros-chefe igualmente os pontuam 13/13, sem nenhuma separação de capacidade.
A verdadeira fronteira, e onde a capacidade dos modelos realmente se diferencia, é o raciocínio sobre as verificações que não estão presentes e o rastreamento de cadeias complexas que nenhuma linha única revela. O caso mais claro é SQL Injection-1 em nosso conjunto de dados, uma injeção indireta através de um alias de coluna que o ORM nunca Escape. Apenas o GPT-5.5 e os modelos GPT-5.6 mais fortes (sol & terra) o rastrearam.
O que a diferença entre média e união nos diz
O número mais útil neste benchmark é a distância entre a execução média de um modelo e a união de suas execuções. Como cada passagem revela um subconjunto diferente dos bugs, agrupá-los (pass@3) recupera uma quantidade surpreendente:
Observe o gpt-5.4-nano: nenhuma execução única atinge 14, mas três execuções agrupadas chegam a 18, um salto de quatro CVEs, porque cada passagem revela bugs diferentes. claude-haiku-4-5 é o caso mais marcante de variância, pontuando 7 em uma execução e 13 em outra do mesmo modelo na mesma tarefa.
A conclusão aqui é que você não precisa ir direto para o modelo mais caro. Três execuções do gpt-5.4-nano custam cerca de US$ 170 e atingem 18/26, o mesmo que uma única passagem de um carro-chefe como o gpt-5.6-terra em média, por uma fração do preço. Três execuções do gpt-5.4-mini (cerca de US$ 460) atingem 20. Repetir um modelo sólido de nível médio supera uma única passagem de um carro-chefe com muito mais frequência do que a diferença de preço sugere.
Um raciocínio superior vale a pena?
Executamos os modelos aplicáveis em dois níveis de raciocínio, o padrão "high" e o mais alto disponível ("xhigh" para os modelos GPT-5.4/5.5 e Claude, "max" para GPT-5.6, grok-4.5 e glm-5.2). Todos os números são uniões pass@3, portanto, são diretamente comparáveis.
As vitórias claras são gpt-5.5 (+3 a 1,5x o custo) e glm-5.2 (+3 a 1,3x). claude-opus-4-8 ganha +2, mas paga o dobro por isso. Em todos os outros lugares, o nível superior compra uma descoberta ou nenhuma, e para gpt-5.6-luna e gpt-5.4-nano, ele ficou um ponto abaixo, dentro do ruído de execução para execução. gpt-5.6-terra é o caso mais acentuado de retornos decrescentes: 2,2x o custo para os mesmos 23.
Os modelos Gemini não possuem configuração acima de "high", então são omitidos desta comparação.
Atualização: Kimi K3
Após escrever este artigo, o Kimi K3 foi lançado. Nós benchmarkamos o Kimi K3 durante o fim de semana e compartilhamos os resultados. O Kimi K3 é o modelo de código aberto mais forte para cibersegurança, muito mais capaz que o GLM-5.2.
Aqui estão os resultados:
- Embora o GPT-5.6-Sol ainda seja mais forte, o Kimi K3 está extremamente próximo e custa uma fração do preço.
- Ele tem um desempenho similar ao GPT-5.6-terra, sendo 15% mais barato
- Utilizando nossa estrutura especializada que gera múltiplos agentes em paralelo, ele é capaz de redescobertar 23/26 CVEs em nossa estrutura, igualando-se aos modelos de ponta e sendo 4x mais barato que o GPT-5.6-Sol, o modelo mais forte da OpenAI!
O benchmark é privado e utiliza CVEs divulgados recentemente. Isso significa que o modelo não foi treinado neles. O desempenho reflete um grande salto nas capacidades dos modelos Kimi.
Conclusão
Aponte um modelo de fronteira para uma base de código, dentro de um harness construído para a tarefa, e ele redescobre a maioria das vulnerabilidades conhecidas. Bugs com um sink perigoso óbvio são resolvidos. Os que ainda separam os modelos não têm um sink para apontar. Uma verificação de autorização ausente, ou uma injeção que você só pode alcançar seguindo uma longa e obscura cadeia por vários arquivos.
O nível mais caro raramente compensa seu preço. Executar um modelo mais barato algumas vezes e agrupar os resultados encontra mais, por menos, do que uma única passagem de um carro-chefe, e essa vantagem só aumenta à medida que os modelos se tornam mais baratos e mais fortes. O harness ainda é o que decide se esse raciocínio é direcionado à parte correta da base de código em primeiro lugar.
