O que medimos, o que não medimos e porquê

Cada caso é um pequeno projeto com o mínimo de código que apresenta, ou evita com segurança, uma vulnerabilidade. Cada um traz um comentário a dizer o que está errado, o que é esperado e porquê. O corpus é versionado: alterá-lo é alterar os números publicados.

O resultado esperado é um juízo sobre o código, decidido antes de o motor correr, nunca uma descrição do que o motor produziu. Quando ambos divergem, investigamos primeiro o motor. Uma etiqueta escrita para coincidir com a saída do motor não mede nada, e já tivemos de corrigir etiquetas que tinham derivado nesse sentido.

Cada caso é analisado tal como uma análise de cliente corre: o orquestrador completo na profundidade máxima, sem scanners externos, sem modelo no ciclo. Os números descrevem o motor entregue de forma idêntica em todo o lado, não uma configuração de laboratório montada para a ocasião.

Um terço do corpus é código não vulnerável, na sua maioria a forma corrigida de um caso que o é. Um corpus feito só de vulnerabilidades não consegue detetar um falso positivo, e os falsos positivos são o que faz uma ferramenta de segurança deixar de ser lida.

Uma afirmação factual: estes ativos existem e estas relações verificam-se entre eles. Mensurável, e a primeira coisa que tencionamos medir. Exige um corpus de repositórios completos anotados à mão, dois revisores independentes e a concordância entre eles publicada ao lado da pontuação. Qualquer coisa menos mede o processo de anotação em vez do extrator.

Factuais, mas apenas quando alguém declara com o que o atacante começa. «Um atacante consegue chegar à base de dados» não é verdadeiro nem falso enquanto não se disser se começa como visitante anónimo, como utilizador autenticado ou como executor de build comprometido. O mesmo motor está certo sob um pressuposto e errado sob outro, portanto um número sem esse pressuposto impresso ao lado não é reproduzível.

Uma afirmação sobre o que importa mais, e não há facto algum independente de um objetivo. Uma startup sem receitas e um banco regulado leem o mesmo repositório e ambos têm razão em ordená-lo de forma diferente. Qualquer ordem «correta» que publicássemos seria a nossa própria opinião de produto, validada contra uma verdade de referência também escrita por nós.

Agir já, planear, verificar: uma recomendação face a uma política, e a política é uma decisão de produto. Podemos testar que segue a sua própria política, que nenhum resultado é descartado em silêncio e que cada recomendação cita evidência existente. Isso é um teste de conformidade. Chamar-lhe exatidão convidaria exatamente à leitura errada que esta página existe para evitar.

Cada camada mostra a partir de quantos resultados a sua precisão foi calculada. As camadas com amostras pequenas são as adicionadas recentemente, e os seus números vão mover-se à medida que o corpus cresce. Isto vale contra as linhas lisonjeiras tanto como contra a incómoda: uma pontuação perfeita sobre nove resultados é uma afirmação fraca, não forte.

Os resultados que o motor produz sobre código não vulnerável são listados com o analisador responsável e a razão pela qual o resultado está errado. São contados contra a precisão, nunca excluídos dela. Três deles disparam sobre a mitigação que a própria regra recomenda, que é precisamente o tipo de defeito que um benchmark existe para trazer à superfície em vez de absorver.

Lê o próprio código de integração de uma aplicação à procura de erros de LLM e de agentes: saída do modelo que chega a uma shell, uma credencial colocada num prompt, uma ferramenta de agente capaz de executar qualquer coisa. Não é uma medida de uma IA dentro da Cybseco. Este benchmark executa o motor determinístico sem qualquer modelo no ciclo.

Uma vulnerabilidade real e fora do alcance atual do motor é registada como lacuna aceite, excluída da revocação e listada. Registar um limite é a forma de uma melhoria futura aparecer como ganho medido em vez de ser proclamada hoje.