Metodología del benchmark
Qué medimos, qué no medimos y por qué
El benchmark existe para ser verificado, no admirado. Esta página expone su perímetro exacto: qué cubren las cifras publicadas, qué dejan fuera deliberadamente y cuáles de nuestras capacidades no pueden reducirse honestamente a un porcentaje.
Qué mide el benchmark
Una pregunta, formulada sobre un corpus versionado de proyectos juzgados a mano: dado un archivo sobre el que ya hemos decidido, ¿informa el motor de la vulnerabilidad que está ahí, en la línea correcta, sin informar de cosas que no existen?
Un corpus versionado
Cada caso es un proyecto pequeño con el mínimo código que presenta, o evita de forma segura, una vulnerabilidad. Cada uno lleva un comentario que dice qué está mal, qué se espera y por qué. El corpus está versionado: cambiarlo es cambiar las cifras publicadas.
Verdad de referencia escrita sobre el código
El resultado esperado es un juicio sobre el código, decidido antes de que el motor se ejecute, nunca una descripción de lo que el motor produjo. Cuando ambos discrepan, investigamos primero el motor. Una etiqueta escrita para coincidir con la salida del motor no mide nada, y hemos tenido que corregir etiquetas que habían derivado en esa dirección.
La cadena que se entrega
Cada caso se analiza igual que se ejecuta un escaneo de cliente: el orquestador completo a profundidad máxima, sin escáneres externos, sin modelo en el bucle. Las cifras describen el motor que se entrega idéntico en todas partes, no una configuración de laboratorio montada para la ocasión.
Código correcto, deliberadamente
Un tercio del corpus es código no vulnerable, en su mayoría la forma corregida de un caso que sí lo es. Un corpus compuesto solo de vulnerabilidades no puede detectar un falso positivo, y los falsos positivos son lo que hace que una herramienta de seguridad deje de leerse.
Qué no mide el benchmark
Cybseco las entrega. Ninguna cifra de la página del benchmark las describe, y cada una lleva su motivo. Una capacidad omitida en silencio es una capacidad que el lector supone cubierta por las cifras.
- Dependency vulnerabilities (SCA) — Produced by external scanners that read a live vulnerability database. Their output changes when the database changes, with no change to Cybseco, so a precision figure measured today would describe the database rather than the engine and would not reproduce tomorrow.
- Standalone secret scanning — Gitleaks is an external binary and is not installed for this benchmark. Hardcoded credentials found by Cybseco's own analyzers are measured, inside the code and CI/CD layers, under CWE-798 and CWE-532.
- Third-party SAST (Semgrep, Bandit) — An external ruleset Cybseco orchestrates but does not author. Measuring it would report Semgrep's accuracy, not Cybseco's.
- Licence compliance policy — A policy decision about a project's licences, not a judgement about its code. The corpus labels vulnerabilities, so a licence finding has nothing to be right or wrong against here.
- LLM-assisted analysis — Its output depends on a model and a prompt rather than on the engine, and it is not part of the deterministic result this benchmark measures.
- Graph, attack paths, decision engine — A different kind of claim: these produce paths and plans, not findings, so precision and recall over labelled lines cannot express them. The methodology page explains what could be measured, and which of these cannot honestly be reduced to a percentage at all. Publishing a number before the method is settled is how a benchmark stops being evidence.
Por qué algunas capacidades no son un porcentaje
La detección tiene una respuesta correcta: la vulnerabilidad está en esa línea o no lo está. Parte de lo que hace Cybseco formula una afirmación de otra naturaleza, y la precisión y la exhaustividad no pueden expresarla. Publicar igualmente una cifra sería lo más fácil de esta página y la forma más rápida de perder la discusión con quien lea con atención.
El grafo de arquitectura
Una afirmación factual: estos activos existen y estas relaciones se dan entre ellos. Medible, y lo primero que pretendemos medir. Requiere un corpus de repositorios completos anotados a mano, dos revisores independientes y la concordancia entre ellos publicada junto a la puntuación. Cualquier cosa menos mide el proceso de anotación en lugar del extractor.
Rutas de ataque
Factual, pero solo una vez que alguien declara con qué empieza el atacante. «Un atacante puede alcanzar la base de datos» no es ni verdadero ni falso hasta que se diga si parte como visitante anónimo, como usuario autenticado o como ejecutor de compilación comprometido. El mismo motor acierta bajo un supuesto y se equivoca bajo otro, de modo que una cifra sin ese supuesto impreso al lado no es reproducible.
Priorización contextual
Una afirmación sobre qué importa más, y no hay hecho alguno independiente de un objetivo. Una startup sin ingresos y un banco regulado leen el mismo repositorio y ambos tienen razón al ordenarlo de forma distinta. Cualquier orden «correcto» que publicáramos sería nuestra propia opinión de producto, validada contra una verdad de referencia que también habríamos escrito nosotros.
El motor de decisión
Actuar ahora, planificar, verificar: una recomendación frente a una política, y la política es una decisión de producto. Podemos comprobar que sigue su propia política, que ningún hallazgo se descarta en silencio y que toda recomendación cita evidencia existente. Eso es una prueba de conformidad. Llamarlo exactitud invitaría exactamente a la lectura errónea que esta página pretende evitar.
Cómo leer las cifras
Cuatro cosas que conviene saber antes de sacar una conclusión de cualquier cifra aislada de la página del benchmark.
Tamaño de la muestra antes que porcentaje
Cada capa muestra a partir de cuántos hallazgos se calculó su precisión. Las capas con muestras pequeñas son las añadidas recientemente, y sus cifras se moverán a medida que su corpus crezca. Esto vale tanto contra las filas halagüeñas como contra la incómoda: una puntuación perfecta sobre nueve hallazgos es una afirmación débil, no fuerte.
Todos los falsos positivos se publican
Los hallazgos que el motor produce sobre código no vulnerable se enumeran con el analizador responsable y el motivo por el que el hallazgo es incorrecto. Se cuentan en contra de la precisión, nunca se excluyen de ella. Tres de ellos se disparan sobre la mitigación que la propia regla recomienda, que es justo el tipo de defecto que un benchmark existe para sacar a la luz en lugar de absorber.
La capa LLM analiza su código
Lee el propio código de integración de una aplicación en busca de errores de LLM y de agentes: salida del modelo que llega a un shell, una credencial colocada en un prompt, una herramienta de agente capaz de ejecutar cualquier cosa. No mide ninguna IA dentro de Cybseco. Este benchmark ejecuta el motor determinista sin ningún modelo en el bucle.
Las lagunas conocidas se nombran
Una vulnerabilidad real y fuera del alcance actual del motor se registra como laguna aceptada, se excluye de la exhaustividad y se enumera. Registrar un límite es la forma de que una mejora futura aparezca como una ganancia medida en lugar de ser proclamada hoy.
Las reglas que nos imponemos
Son restricciones sobre nosotros, no afirmaciones sobre el producto. Son lo que hace que las cifras merezcan ser leídas.
- Todo lo que Cybseco anuncia está medido o bien nombrado en esta página como fuera de alcance. No hay un tercer estado, y una verificación automática hace fallar la compilación cuando un analizador se entrega sin una cosa u otra.
- La verdad de referencia describe el código y se decide antes de que el motor se ejecute. Una etiqueta escrita para coincidir con la salida del motor no es evidencia.
- Una cifra se publica junto con la muestra a partir de la cual se calculó.
- Un defecto que conocemos se publica, no se excluye de la métrica. Una verificación también falla cuando un defecto publicado deja de reproducirse en silencio, de modo que la lista solo puede encogerse honestamente.
- Ninguna comparación con otro producto en capacidades donde seríamos nosotros quienes eligiéramos su configuración, su corpus y el escenario. Nadie debería creerse una comparación así, nosotros incluidos.
- Ninguna cifra antes de que su metodología sea pública y su verdad de referencia inspeccionable.
Vea a Cybseco razonar sobre un sistema real
Vea la demo interactiva y luego solicite una prueba guiada para su equipo.