Cómo leer estas cifras
Precisión
De todas las alertas que genera el escáner, la proporción que son vulnerabilidades reales. Precisión baja = muchos falsos positivos que revisar.
Definición completa en el glosario ↗Recall
De todas las vulnerabilidades reales que existen, la proporción que el escáner realmente encuentra. Recall bajo = se pasan por alto fallos reales — el modo de fallo más peligroso.
Definición completa en el glosario ↗F1
Una sola cifra que combina precisión y recall. Cómodo para comparar, pero oculta cuál de los dos está afectando el resultado — por eso esta página publica ambos por separado, no solo el F1.
Definición completa en el glosario ↗Cinco metodologías, no una sola cifra
Una única cifra de "precisión" casi no significa nada sin saber cómo se midió. Estas cinco producen resultados muy distintos — y cada vez más honestos:
Fixtures internos
Ejecuta cada regla contra sus propios casos de prueba emparejados (un archivo vulnerable, uno limpio por regla) — 910 casos en los 8 lenguajes. Esto mide si el motor de reglas sigue haciendo lo que fue diseñado para hacer; un conjunto de reglas maduro debería puntuar cerca del 100% aquí casi por construcción. Útil como señal de regresión, no como prueba externa de nada.
OWASP Benchmark (Java + Python)
Una suite de pruebas independiente, de terceros (no escrita por nosotros), con una verdad de referencia fija y publicada, ejecutada por completo para ambos lenguajes. Más difícil y realista que fixtures caseros — es la misma metodología que usan los estudios de benchmarking de la industria. Construida casi enteramente en torno a patrones de código Servlet/HTTP.
NIST Juliet (Java)
Una suite de pruebas sintética del gobierno de EE.UU. (NIST SARD), 6.616 casos en 6 categorías CWE mapeadas. Mismo lenguaje y en gran medida las mismas clases de vulnerabilidad que OWASP Benchmark Java, pero con idiomas de código fuente mucho más variados — variables de entorno, archivos de propiedades, sockets, entrada estándar, conexiones URL, no solo peticiones HTTP. La brecha entre este y OWASP Benchmark Java es en sí misma la señal más honesta de esta página.
Suite de pruebas CVE
Reconstruida a partir de 45 CVE reales e históricas en 8 frameworks del mundo real (Django, Flask, Express, Spring, ASP.NET, Laravel, más las bibliotecas estándar de ambos lenguajes). La prueba más dura: código vulnerable real tal como se publicó, no un caso de prueba idealizado.
Resultados, ejecutados hoy
| Metodología | Casos | Precisión | Recall | F1 |
|---|---|---|---|---|
| Fixtures internos (8 lenguajes) autovalidación |
910 | 100.0% | 100.0% | 100.0% |
| OWASP Benchmark (Java) independiente |
2.740 | 73.7% | 100.0% | 84.8% |
| NIST Juliet (Java) independiente |
6.616 | 98.4% | 46.7% | 63.3% |
| OWASP Benchmark (Python) independiente |
1.230 | 78.8% | 96.0% | 86.5% |
| Suite de pruebas CVE (5 lenguajes) mundo real |
45 | 82.9% | 75.6% | 79.1% |
La comparación más reveladora de esta página es Java contra sí mismo: OWASP Benchmark Java muestra 100,0% de recall, mientras que NIST Juliet — mismo lenguaje, en gran medida las mismas clases CWE, ejecutado la misma semana — muestra solo 46,7%. No es una contradicción, es un diagnóstico. OWASP Benchmark está construido casi enteramente en torno a código fuente de estilo Servlet/HTTP; Juliet también prueba variables de entorno, archivos de propiedades, sockets, entrada estándar y conexiones URL. El motor de reglas había sido calibrado exactamente hacia el patrón que OWASP Benchmark premia, y Juliet expuso ese punto ciego. Ya hemos corregido parte de esa brecha en este ciclo (el recall de Java en Path Traversal e Inyección SQL prácticamente se duplicó tras ampliar las fuentes de taint reconocidas — ver más abajo — y la precisión apenas cambió: 98,2% → 98,4%) y las cifras actuales de esta página reflejan esa corrección, no las anteriores. El recall de OWASP Benchmark Python (96,0%) y de la suite de pruebas CVE (75,6%) se sitúan entre ambos, lo cual es en sí mismo informativo: ni tan estrechamente enfocado como OWASP Java, ni tan amplio como Juliet. Cifras idénticas en las cinco habrían sido la señal de que algo fallaba en la metodología, no en la herramienta — una dispersión tan amplia, con una causa identificada, es lo que parece un benchmark honesto.
OWASP Benchmark Java, desglosado por categoría
La ejecución independiente más grande y más dura — 2.740 casos, cero falsos negativos en cada una de las 11 categorías, pero la precisión varía marcadamente según la categoría. De peor a mejor:
| Categoría | Precisión | Recall |
|---|---|---|
| Inyección XPath | 42.9% | 100.0% |
| Inyección LDAP | 45.8% | 100.0% |
| Inyección de comandos | 50.2% | 100.0% |
| Inyección SQL | 55.4% | 100.0% |
| Violación de límite de confianza | 65.9% | 100.0% |
| Recorrido de rutas | 79.6% | 100.0% |
| Hash débil | 79.6% | 100.0% |
| Criptografía débil | 100.0% | 100.0% |
| Aleatoriedad débil | 100.0% | 100.0% |
| XSS | 100.0% | 100.0% |
| Cookie insegura | 100.0% | 100.0% |
La lectura honesta: el recall es perfecto en todas partes (cada vulnerabilidad plantada se detecta, en cada categoría), pero cuatro categorías con mucho taint — inyección XPath, inyección LDAP, inyección de comandos, inyección SQL — están por debajo del 56% de precisión, lo que significa que el motor de reglas sobre-detecta en esos patrones específicos en esta suite sintética. Las comprobaciones de criptografía débil, aleatoriedad débil, XSS y cookie insegura son exactas (100%/100%). Este es el compromiso real actual: ajustado para no pasar nunca por alto una vulnerabilidad plantada, a costa de más falsos positivos de los que quisiéramos en un puñado de categorías de inyección.
NIST Juliet Java, desglosado por categoría
La ejecución más grande de esta página — 6.616 casos en las 6 categorías CWE para las que Juliet 1.3 realmente aporta datos (3 de las 9 previstas inicialmente — XXE, aleatoriedad débil, validación de certificados, deserialización — no tienen equivalente en esta descarga del NIST). Peor recall primero:
| Categoría | Precisión | Recall |
|---|---|---|
| Inyección LDAP | 98.8% | 11.4% |
| Recorrido de rutas (absoluto) | 100.0% | 33.0% |
| Inyección SQL | 98.4% | 41.9% |
| Recorrido de rutas (relativo) | 97.5% | 64.5% |
| Criptografía débil | 100.0% | 89.5% |
| Inyección de comandos | 98.3% | 99.4% |
La precisión se mantiene alta en todas partes (97,5–100%) — el motor de reglas rara vez da falsas alarmas — pero el recall varía enormemente, y la razón es arquitectónica, no aleatoria. Dos de las doce variantes de código fuente por categoría de Juliet (dato leído mediante una llamada a base de datos, o pasado a través de una "variante de flujo" con método abstracto) viven en un archivo de clase acompañante que el escáner de un solo archivo del benchmark nunca ve — esos casos son inalcanzables sin importar la calidad de las reglas, y bajan el techo de cada categoría. Dentro de lo que realmente es alcanzable, la inyección LDAP es el punto débil actual: los casos de prueba LDAP de Juliet se apoyan en patrones de fuente (búsquedas de contexto JNDI alimentadas por datos de configuración/entorno) que este conjunto de reglas todavía no reconoce como fuentes de taint, a diferencia de las reglas de recorrido de rutas e inyección SQL que se acaban de ampliar. Es una brecha acotada y divulgada, no oculta.
Fixtures internos, desglosados por lenguaje (autovalidación)
La ejecución interna de 910 casos, por lenguaje — de nuevo: esto mide consistencia interna, no dificultad externa, ya que cada caso es un fixture escrito para una regla que existe.
| Lenguaje | Casos vulnerables | Detectados |
|---|---|---|
| Python | 144 | 144/144 |
| JavaScript/TypeScript | 84 | 84/84 |
| Java | 55 | 55/55 |
| HTML | 38 | 38/38 |
| YAML | 33 | 33/33 |
| PHP | 27 | 27/27 |
| C# | 25 | 25/25 |
| Otro (Dockerfile + genérico) | 10 | 10/10 |
Suite de pruebas CVE, desglosada por framework
La prueba más dura y realista — 45 casos reconstruidos a partir de CVE reales publicadas — desglosada honestamente, incluyendo dónde falla:
| Framework | Lenguaje | Precisión | Recall |
|---|---|---|---|
| Flask | Python | 100.0% | 100.0% |
| Django | Python | 100.0% | 100.0% |
| Spring | Java | 87.5% | 70.0% |
| Laravel | PHP | 100.0% | 66.7% |
| PHP stdlib | PHP | 80.0% | 66.7% |
| Python stdlib | Python | 100.0% | 66.7% |
| Express | JavaScript | 72.7% | 80.0% |
| ASP.NET | C# | 66.7% | 66.7% |
Punto débil divulgado honestamente: ASP.NET/C# y Express/JavaScript están en la parte más baja de esta tabla — precisión y recall en el rango 66-80%. CVE históricas como cadenas de deserialización tipo log4shell o rutas de taint multi-salto complejas en estos frameworks son los casos concretos que el motor de reglas todavía no detecta (los 11 falsos negativos incluyen el propio CVE-2021-44228, registrado como brecha abierta, no oculta).
Qué deja fuera deliberadamente esta página
- HTML, YAML y Dockerfile no aparecen en ninguna tabla anterior. No son clases de vulnerabilidad de inyección estilo CWE como la inyección SQL o el XSS — las reglas YAML apuntan a errores de configuración de pipelines CI/CD y las reglas de Dockerfile son comprobaciones de higiene (usuario root, imagen base sin fijar), arquitectónicamente distintas de un benchmark de precisión/recall construido en torno a vulnerabilidades plantadas. Vea la guía de escaneo CI/CD para lo que realmente se detecta ahí.
- Las suites NIST Juliet C/C++ y .NET/C# existen y podrían extender esta página a más lenguajes — aún no incorporadas. La propia Juliet Java solo tiene 6 de sus 112 categorías CWE mapeadas aquí (ver arriba); ampliar la cobertura a las otras 103 (muchas sin regla equivalente alguna, p.ej. desbordamiento de enteros, condición de carrera) es trabajo futuro, no un resultado oculto.
Por qué no hay ninguna puntuación de competidores en esta página
Buscamos. Existen cifras públicas de OWASP Benchmark para algunos competidores, pero provienen del propio contenido de marketing de un proveedor competidor, y una segunda fuente encontrada para la misma herramienta reporta una cifra notablemente distinta para el mismo benchmark reclamado — sin metodología, versión de suite de pruebas ni versión de herramienta divulgada en ninguna de las dos. Eso no es algo que estemos dispuestos a repetir como un hecho. Si un competidor publica una puntuación de benchmark con una metodología transparente y reproducible, la citaremos, exactamente como el resto de esta página cita metodología y fechas. Hasta entonces, esta página compara StaticCodeAudit con la realidad, no con cifras no verificables sobre otras herramientas.
Reproducir estas cifras
Estas cuatro metodologías se ejecutan mediante herramientas de evaluación internas, separadas del código fuente del producto — NIST Juliet y OWASP Benchmark son suites de prueba de terceros, no código que hayamos escrito, por lo que no se distribuyen con la herramienta. No es algo que los usuarios finales ejecuten día a día; es el mismo tooling que produjo las cifras de arriba, ejecutado contra el mismo motor de reglas.
run_benchmark.py owasp
run_benchmark.py owasp-python
run_benchmark.py cve
run_benchmark.py julietCada ejecución exporta un archivo JSON fechado con el desglose completo por categoría — las tablas de esta página están transcritas directamente de esos exports, ejecutados entre el 7 y el 9 de agosto de 2026 (las dos ejecuciones más grandes, OWASP Benchmark Java y NIST Juliet Java, tardaron 3.551 y 4.611 segundos respectivamente — menos de 1h30 cada una — en 2.740 y 6.616 casos).
Preguntas frecuentes
¿Por qué el score de fixtures internos muestra 100% cuando los otros dos no?
Porque mide algo distinto. Los fixtures internos son casos de prueba emparejados escritos específicamente para cada regla — una regla que no pudiera detectar su propio caso de prueba diseñado sería una regla rota, no un fallo sutil. 100% ahí significa que el motor de reglas no tiene regresiones evidentes, no que la detección sea infalible en el mundo real. OWASP Benchmark y la suite CVE son independientes del proceso de escritura de reglas, por eso sus cifras son más bajas y más significativas.
¿Es un problema una precisión/recall del 66-80% en algunos frameworks de la suite CVE?
Es una limitación real y divulgada, no algo que maquillar. Los flujos de taint multi-salto complejos y los gadgets de deserialización específicos de framework (el tipo detrás de CVE-2021-44228) son genuinamente difíciles de detectar de forma consistente para un analizador estático basado en reglas, comercial u open source. Esta página existe precisamente para que esa limitación sea visible en lugar de quedar enterrada bajo una única cifra inflada en grande.
¿Por qué la precisión de OWASP Benchmark Java es solo del 73,7% cuando el recall es un 100% perfecto?
Porque el motor de reglas está actualmente ajustado para no pasar nunca por alto una vulnerabilidad plantada, y eso tiene un coste: cuatro categorías — inyección XPath, inyección LDAP, inyección de comandos, inyección SQL — se sitúan entre el 43% y el 55% de precisión, lo que significa más falsos positivos de los deseados en esos patrones de taint específicos en esta suite sintética. Las otras siete categorías, incluidas XSS y la criptografía débil, son exactas. Esta es una limitación real y actual, divulgada aquí en lugar de suavizada bajo un score F1 agregado.
OWASP Benchmark Java muestra 100% de recall pero NIST Juliet Java solo 46,7% — mismo lenguaje, CWE similares. ¿Cuál tiene razón?
Ambos, para lo que cada uno mide — y la brecha entre ambos es el hallazgo real. OWASP Benchmark está construido casi enteramente en torno a patrones de fuente Servlet/HTTP; Juliet también ejercita variables de entorno, archivos de propiedades, sockets, entrada estándar y conexiones URL como fuentes de taint. El motor de reglas había sido calibrado hacia el patrón que OWASP Benchmark premia, y Juliet lo expuso. Ya hemos corregido parte de ello — el recall en Path Traversal e Inyección SQL prácticamente se duplicó en este ciclo tras ampliar las fuentes de taint reconocidas, con una precisión esencialmente sin cambios (98,2% → 98,4%) — y las cifras actuales de esta página reflejan esa corrección, no las anteriores. La inyección LDAP es la siguiente brecha conocida.
Vea usted mismo la salida de detección en bruto
Abra el informe de demostración en vivo — sin instalación, sin registro — e inspeccione hallazgos reales directamente.
Abrir el informe en vivo Ver lenguajes soportados