Snyk VulnBench JS 1.0: ¿Pueden los LLM encontrar los mismos errores dos veces?

Ejecutamos 300 análisis de vulnerabilidades para medir qué tan repetible es una revisión de seguridad con un LLM agéntico sobre el mismo código, prompt y entorno. El resultado principal no es que un escáner "gane" en una clasificación autorreferencial. Es que los hallazgos de seguridad de los LLM son poco consistentes: los hallazgos coincidentes con la referencia fueron estables, pero los informes adicionales de los modelos variaron mucho de una ejecución a otra.

En pocas palabras, cuando Claude reportó errores que no estaban en la lista de referencia de Snyk Code, esos informes adicionales solían ser inconsistentes. En 250 ejecuciones del modelo, 80 de los 161 hallazgos únicos que no coincidían con la referencia aparecieron en solo una de cinco repeticiones idénticas, mientras que solo 22 aparecieron en las cinco. Pero cuando Claude coincidió con un hallazgo de referencia, su comportamiento fue mucho más estable: 134 de los 158 hallazgos únicos coincidentes con la referencia aparecieron en las cinco repeticiones. Esa diferencia es el resultado central de Snyk VulnBench JS 1.0.

El benchmark también muestra complementariedad. Los modelos identificaron de forma consistente patrones de explotación conocidos y de alta señal y, en un caso, revelaron una posible brecha en los hallazgos de Snyk Code. Snyk Code SAST fue determinista y mejor para enumerar sistemáticamente los puntos de destino repetidos en los flujos de datos, además de mantener tiempos de ejecución considerablemente rápidos para el análisis de vulnerabilidades. Ninguno de estos resultados respalda reemplazar una técnica por la otra. Los datos respaldan combinarlas.

Aspectos destacados:

• La configuración de LLM con mayor exhaustividad encontró solo el 81% de las vulnerabilidades de referencia de Snyk Code.

• La configuración de LLM con la mejor puntuación alcanzó un F1 de 75.4% respecto a la referencia de Snyk, una brecha de 24.6 puntos frente a la reproducción determinista de la referencia por SAST.

• Casi el 50% de los informes de vulnerabilidades exclusivos de los LLM apareció en solo 1 de 5 análisis idénticos.

• El LLM con mayor exhaustividad también generó la cola más ruidosa: el 41% de sus informes quedó fuera del conjunto de referencia de Snyk Code.

• En el fixture más grande y similar a una aplicación, el mejor modelo obtuvo solo un F1 de 40.0% respecto a la referencia de Snyk y no detectó repetidamente vulnerabilidades de recorrido de rutas y de límites de recursos.

Por qué la revisión de seguridad con LLM necesita ser repetible

Los agentes de programación ya forman parte del ciclo de desarrollo. Escriben código, modifican pull requests, explican cambios y cada vez se usan más para revisar la seguridad del código y de las aplicaciones antes de que una persona lea las diferencias. Por eso, la confiabilidad es una cuestión de producto: si el mismo agente ve dos veces el mismo código vulnerable, ¿reporta dos veces los mismos problemas de seguridad?

Las herramientas SAST tradicionales están diseñadas para ser deterministas. Si el código y las reglas no cambian, el resultado tampoco debería cambiar. Los LLM son diferentes. Pueden razonar sobre código desconocido, describir riesgos con un lenguaje útil y, a veces, detectar problemas que un analizador estático no encuentra. Pero también pueden variar entre ejecuciones, reportar en exceso problemas relacionados o detenerse después de encontrar un ejemplo representativo de un patrón repetido.

Snyk VulnBench JS 1.0 se diseñó para cuantificar ese comportamiento. El benchmark usa aplicaciones pequeñas de JavaScript y Express, para que cada ejecución pueda inspeccionarse. El objetivo no es simular un monorepo completo, sino medir el comportamiento del modelo en condiciones repetidas y controladas.

Diseño del benchmark: 300 análisis de seguridad repetidos

El benchmark incluye 10 proyectos fixture de JavaScript con 44 hallazgos de referencia de Snyk Code. Cada fixture es una aplicación pequeña basada en Express, desde fragmentos compactos de un solo archivo hasta una aplicación de tareas más grande con rutas de servidor, estado de base de datos, cargas de archivos y JavaScript de frontend.

Evaluamos seis configuraciones:

Cada configuración ejecutó cada tarea cinco veces: 10 tareas x 6 configuraciones x 5 repeticiones = 300 ejecuciones. Las configuraciones de los modelos usaron el mismo prompt de auditoría directa y devolvieron los hallazgos como JSON estructurado. El modelo podía leer los archivos del proyecto, pero no el archivo de referencia findings.json.

Snyk Code define el conjunto de referencia de este benchmark. Eso significa que su puntuación del 100% no es una afirmación de precisión respecto a todas las vulnerabilidades posibles de los proyectos. Significa que Snyk Code reprodujo sus propios hallazgos de referencia de forma determinista en ejecuciones repetidas. Usamos ese conjunto de referencia para medir la concordancia y la variación de los modelos, así como los puntos en los que su comportamiento diverge.

El evaluador es intencionalmente flexible: se acredita un hallazgo del modelo si reporta el mismo tipo de vulnerabilidad que uno de referencia. No es necesario que coincidan el archivo, la línea, la gravedad ni la ruta de origen a destino. Reportamos el F1 respecto a la referencia de Snyk: la media armónica de precisión y exhaustividad cuando los hallazgos de Snyk Code se consideran el conjunto de referencia. Es útil como métrica de concordancia, pero no es el punto principal.

Como este benchmark no usa un conjunto de referencia independiente y exhaustivamente verificado, el F1 respecto a la referencia de Snyk no debe interpretarse como una medida de la precisión real de detección de vulnerabilidades. Un modelo con menor concordancia con el conjunto de referencia de Snyk Code aún podría obtener mejores resultados frente a una referencia independiente si algunos de sus hallazgos no coincidentes son válidos o si evita problemas que el conjunto de referencia exagera. En este informe, el F1 respecto a la referencia de Snyk responde una pregunta más acotada: ¿qué tan estrechamente y con qué consistencia coinciden los hallazgos del modelo con los hallazgos de referencia de Snyk Code?

Resultado 1: la repetibilidad de los LLM varió según la configuración del modelo

A nivel de configuración, la repetibilidad se refleja en la relación entre la puntuación y la variación. El mejor resultado se encuentra hacia la esquina superior izquierda: alta concordancia con el conjunto de referencia y poca variación entre ejecuciones repetidas. Snyk Code SAST ocupa esa esquina, con un F1 de 100.0% respecto a la referencia de Snyk y una desviación estándar de 0.0 puntos porcentuales, porque reprodujo su conjunto de referencia de forma determinista. Las configuraciones de los modelos Claude se dispersan hacia abajo y a la derecha; Claude Sonnet 4.6 High presenta la mayor variación general, con 3.5 puntos porcentuales.

Figura 1: F1 respecto a la referencia de Snyk en función de la desviación estándar del F1 general respecto a la referencia de Snyk. Los mejores puntos se acercan a la esquina superior izquierda: mayor puntuación de concordancia y menor variación entre ejecuciones repetidas. Snyk Code SAST aparece resaltado en morado, con variación cero.

El diagrama de dispersión permite ver dos cosas a la vez. Primero, el rol de Snyk Code en este benchmark es reproducir determinísticamente la referencia, no realizar una revisión probabilística. Segundo, las configuraciones de los modelos no se ordenan por costo ni por actualidad: Claude Opus 4.6 Medium y High están cerca, con poca variación y el F1 más alto entre los modelos, mientras que Claude Opus 4.7 Max y Claude Sonnet 4.6 High están más a la derecha, lo que significa que sus resultados variaron más entre ejecuciones.

En todas las configuraciones de los modelos, 80 de las 161 firmas de hallazgos únicos que no coincidían con la referencia aparecieron en solo una de cinco ejecuciones repetidas. Ese total explica parte de la variación, pero también analizamos una perspectiva potencialmente más útil: el desglose por modelo:

Figura 2: Proporción de las firmas de hallazgos únicos que no coinciden con la referencia de cada configuración del modelo y que aparecieron en solo una de cinco ejecuciones repetidas. Firma = tarea + tipo de vulnerabilidad + archivo + línea, agrupados por configuración del modelo.

La siguiente tabla muestra los valores exactos del gráfico anterior, además de los dos indicadores de estabilidad más importantes.

La inestabilidad no se distribuye de manera uniforme entre los modelos. Claude Sonnet 4.6 Medium generó la mayor cantidad de hallazgos únicos que no coincidían con la referencia, con 60 firmas; 37 de ellas aparecieron en solo una de cinco ejecuciones. Claude Sonnet 4.6 High y Claude Opus 4.7 Max mostraron un patrón similar: muchos informes adicionales aparecieron una sola vez y no volvieron a aparecer. En cambio, el 0.0% de Claude Opus 4.6 Medium en el gráfico indica una alta estabilidad y pocos hallazgos aislados: todos sus informes adicionales aparecieron en dos o más ejecuciones, y ninguno apareció en solo una de las cinco repeticiones.

Las configuraciones de Opus 4.6 se comportaron de manera diferente. Produjeron muchos menos hallazgos que no coincidían con la referencia y sus informes adicionales fueron más estables. Eso no significa que todos esos informes sean correctos, pero sí cambia la interpretación operativa: menos hallazgos inesperados, menos afirmaciones aisladas y menos trabajo adicional de clasificación.

El siguiente gráfico destaca cómo la mayoría de las configuraciones que no son Opus 4.6 tuvieron dificultades para mantener la estabilidad de sus hallazgos adicionales (no coincidentes) entre ejecuciones repetidas. Claude Sonnet 4.6 Medium y High mostraron poca repetibilidad: solo el 8.3% y el 9.3% de sus hallazgos no coincidentes, respectivamente, se mantuvo en las cinco ejecuciones. Claude Opus 4.7 Max también tuvo un resultado bajo, con solo un 16.7% de estabilidad. En cambio, Opus 4.6 Medium y High mostraron mucha más estabilidad en sus hallazgos no coincidentes (60.0% y 50.0%, respectivamente), lo que subraya la menor predictibilidad y el mayor ruido de los hallazgos no coincidentes de Sonnet y de la configuración más reciente Claude Opus 4.7 Max.

Figura 3: Proporción de firmas de hallazgos únicos que no coinciden con la referencia y que aparecieron en las cinco ejecuciones repetidas de cada configuración del modelo.

Los hallazgos coincidentes cuentan otra historia. Cuando un modelo encontró un hallazgo de referencia de Snyk Code, por lo general volvió a encontrarlo en las siguientes ejecuciones. Claude Opus 4.6 Medium coincidió con 25 hallazgos únicos de referencia y repitió los 25 en cinco ejecuciones. Claude Opus 4.6 High repitió 25 de 26. Incluso las configuraciones Sonnet más ruidosas repitieron 29 de los 36 hallazgos coincidentes con la referencia.

Figura 4: Proporción de hallazgos únicos de referencia de Snyk Code con los que cada configuración del modelo coincidió en las cinco ejecuciones repetidas.

La Figura 4 muestra el lado de los hallazgos coincidentes en la historia de la repetibilidad. En todas las configuraciones de los modelos, 134 de 158 hallazgos únicos coincidentes con la referencia aparecieron en las cinco repeticiones (84.8%). Esto significa que, cuando un modelo detectó un hallazgo de referencia conocido de Snyk Code, por lo general lo hizo de forma confiable. El contraste con la Figura 5 es el resultado principal: los verdaderos positivos fueron generalmente estables, mientras que los informes adicionales que no coincidían con la referencia generaron mucho más ruido.

Figura 5: Distribución de hallazgos únicos de los modelos que no coinciden con la referencia, según la frecuencia con la que apareció la misma firma de hallazgo en cinco repeticiones de la misma tarea y configuración del modelo. Firma = tarea + configuración + tipo de vulnerabilidad + archivo + línea.

Casi la mitad de los hallazgos únicos de los modelos que no coincidían con la referencia apareció en solo una de cinco repeticiones idénticas. Esto representa un problema práctico de confiabilidad: un desarrollador podría recibir una cola de revisión considerablemente diferente según la ejecución que se realice.

La distribución exacta que muestra el gráfico es:

Resultado 2: los agentes LLM y SAST encontraron distintas brechas de seguridad

La interpretación más útil no es "LLM contra SAST", sino "LLM más SAST detectan distintos tipos de fallas".

La forma más clara de verlo es por clase de vulnerabilidad. El siguiente mapa de calor muestra la exhaustividad media frente al conjunto de referencia de Snyk Code, desglosada por tipo de vulnerabilidad y configuración. Snyk Code aparece con un 100% porque define y reproduce el conjunto de referencia. Las filas de los modelos muestran en qué casos la revisión agéntica coincide con ese conjunto de referencia y en cuáles se queda corta.

Figura 6: Exhaustividad media frente al conjunto de referencia de Snyk Code, por tipo de vulnerabilidad y configuración. Snyk Code se muestra como reproducción determinista de la referencia; las filas de los modelos muestran en qué clases la revisión agéntica coincide o se queda corta.

Las configuraciones de modelos tuvieron mejores resultados con patrones de explotación conocidos y de alta señal: a menudo detectaron correctamente la inyección de comandos, la inyección de código, las credenciales codificadas de forma fija, la inyección SQL, SSRF, la redirección abierta, la contaminación de prototipos y ReDoS. Tuvieron más dificultades con los hallazgos de límites de recursos, la sanitización inadecuada, la validación de tipos, el transporte inseguro, la exposición de información del framework y los flujos repetidos de traversal de rutas.

Ese patrón se observa en js-project-tigerteam, donde todas las configuraciones de modelos detectaron sistemáticamente la contraseña de la base de datos codificada de forma fija, XSS reflejado, traversal de rutas e inyección de comandos en las 25 repeticiones de cada modelo.

1app.get("/greet", (req, res) => {
2  const name = req.query.name;
3  res.send(`<html><body><h1>Hello, ${name}!</h1></body></html>`);
4});
5
6app.get("/file", (req, res) => {
7  const filename = req.query.filename;
8  const basePath = "/var/app/public/";
9  fs.readFile(basePath + filename, "utf8", (err, data) => {
10    if (err) return res.status(404).send("Not found");
11    res.send(data);
12  });
13});
14
15app.get("/ping", (req, res) => {
16  const host = req.query.host;
17  exec("ping -c 1 " + host, (err, stdout, stderr) => {
18    if (err) return res.status(500).send("Error");
19    res.send(`<pre>${stdout}</pre>`);
20  });
21});

Pero el mismo fixture incluía una función auxiliar simulada con apariencia de SQL:

1function dbQuery(sql) {
2  console.log("Query:", sql);
3  return [];
4}
5
6app.get("/users", (req, res) => {
7  const username = req.query.username;
8  const sql = "SELECT * FROM users WHERE username = '" + username + "'";
9  const results = dbQuery(sql);
10  res.json(results);
11});

Los modelos reportaron inyección SQL en 25 de las 25 ejecuciones del modelo en js-project-tigerteam. En este fixture, Snyk Code acertó al no reportarla: dbQuery() registra la cadena y devuelve un arreglo vacío. No hay ningún punto de ejecución de SQL. Este es el tipo de caso en que un LLM puede confundir código que parece vulnerable con una vulnerabilidad explotable.

js-project-nightowl mostró la lección opuesta. Las 25 ejecuciones del modelo reportaron inyección SQL fuera del conjunto de referencia de Snyk Code, y esta vez es probable que la señal del modelo sea valiosa:

1deleteTodo: (id) => db.prepare("DELETE FROM todos WHERE id = " + id).all(),

Ese hallazgo se contó como no coincidente porque no estaba en el conjunto de referencia de Snyk Code. No debería descartarse como una alucinación. Probablemente sea una brecha real del producto que conviene investigar. El benchmark es más sólido, no menos, porque reveló ese caso, y estamos incorporando internamente estos aprendizajes para mejorar las capacidades de detección de Snyk.

Figura 7: Promedio de reportes no coincidentes por ejecución del modelo, por tipo de vulnerabilidad y configuración del modelo. Incluyen falsos positivos del modelo, comentarios de revisión relacionados y posibles brechas del producto fuera del conjunto de referencia de Snyk Code.

Este segundo mapa de calor muestra la otra cara de la complementariedad: los reportes adicionales de los modelos no forman una categoría homogénea. Algunos probablemente sean falsos positivos, como la función auxiliar simulada con apariencia de SQL, pero no ejecutable, en js-project-tigerteam. Otros son comentarios relacionados con la revisión de seguridad que quedan fuera del alcance del conjunto de referencia. Y algunos, como el reporte de inyección SQL en js-project-nightowl, probablemente sean hallazgos válidos que deberían contribuir a mejorar la cobertura de Snyk Code.

La complementariedad también funciona en sentido inverso. js-project-nightowl es el fixture más parecido a una aplicación de JS 1.0: server.js tiene 198 líneas, y db.js y public/app.js suman otras 183 líneas de JavaScript. Incluye rutas, cargas, eliminación de archivos adjuntos, descargas y estado de la base de datos. Claude Opus 4.6 High fue perfectamente estable en este fixture, pero con solo 40.0% de F1 respecto de la referencia de Snyk. En cinco repeticiones, no detectó ninguno de los hallazgos de referencia de traversal de rutas ni dos de las tres oportunidades de detectar límites de recursos.

Figura 8: Puntuación promedio del benchmark en el fixture más grande, compuesto por varios archivos. Las barras de error muestran la desviación estándar entre ejecuciones repetidas.

El patrón de hallazgos omitidos abarcó flujos repetidos de archivos adjuntos:

1if (req.file) {
2  if (existing.attachment_stored_name) {
3    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
4  }
5  updates.push("attachment_original_name = ?", "attachment_stored_name = ?");
6  values.push(req.file.originalname, req.file.filename);
7} else if (req.body.removeAttachment === true || req.body.removeAttachment === "true") {
8  if (existing.attachment_stored_name) {
9    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
10  }
11}

El modelo encontró algunos problemas representativos, pero no logró enumerar todos los puntos vulnerables repetidos. Es precisamente ahí donde el análisis determinista del flujo de datos resulta valioso. La cobertura de SAST y la revisión con modelos no son duplicados; son instrumentos distintos con puntos ciegos diferentes.

Resultado 3: Las ejecuciones de LLM más costosas no ofrecieron mejor cobertura

Claude Opus 4.7 Max fue la configuración de modelo más costosa en esta prueba, pero no la de mejor rendimiento. En promedio, consumió 95,969 tokens y costó $0.3559 por sesión del modelo. Claude Opus 4.6 Medium consumió en promedio 51,574 tokens y costó $0.0628 por sesión. Por lo tanto, Opus 4.7 Max cuesta 5.67 veces más y usa 1.86 veces más tokens, pero obtiene una puntuación menor: 68.8% de F1 respecto de la referencia de Snyk, frente al 75.4% de Opus 4.6 Medium.

Figura 9: Relación entre costo y calidad solo de los modelos. Los mejores puntos se acercan a la esquina superior izquierda: mayor F1 respecto de la referencia de Snyk con un menor costo estimado por sesión del modelo.

Los montos en dólares son pequeños porque los fixtures son pequeños. Pero la cuestión de cómo escalan no lo es. Las comprobaciones de seguridad reales se ejecutan durante sesiones de agentes de programación, commits, pull requests y trabajos de CI en repositorios que son órdenes de magnitud más grandes que estos fragmentos. Una inferencia más costosa no ofrece automáticamente una mejor cobertura de seguridad.

Puntuaciones de coincidencia con el conjunto de referencia de Snyk Code

La F1 respecto de la referencia de Snyk sigue siendo útil, siempre que se describa con precisión: mide la coincidencia con el conjunto de referencia de Snyk Code. Con esta métrica, Snyk Code SAST reprodujo su conjunto de referencia con una F1 del 100.0% respecto de la referencia de Snyk y una desviación estándar de la puntuación de 0.0 puntos porcentuales. La configuración de modelo con mejor resultado fue Claude Opus 4.6 Medium, con 75.4% de F1 respecto de la referencia de Snyk, 68.0% de recall y 91.5% de precisión.

Esta tabla no debe interpretarse como «Snyk demostró que Snyk tiene una precisión del 100%». Debe interpretarse así: Snyk Code generó un conjunto de referencia determinista; los modelos coincidieron parcialmente con él; y las diferencias revelan aspectos de reproducibilidad, costo y cobertura que vale la pena medir.

Qué significa este benchmark para la revisión de seguridad con LLM

El conjunto de referencia proviene de Snyk Code. Es transparente y reproducible, pero se vuelve circular si se considera una verdad universal. Este informe no hace esa afirmación. El benchmark mide la coincidencia de los modelos con los hallazgos de Snyk Code y usa las divergencias para estudiar la reproducibilidad y la complementariedad.

El método de evaluación es generoso. Compara por tipo de vulnerabilidad, no por archivo, línea, gravedad o identidad exacta del origen al destino. Un método más estricto probablemente reduciría las puntuaciones de coincidencia de los modelos y revelaría más errores al confundir flujos duplicados.

Los fixtures son aplicaciones pequeñas de JavaScript y Express. Sirven para hacer mediciones controladas, pero no abarcan monorepos grandes, aplicaciones TypeScript con muchos frameworks, arquitecturas de varios servicios ni vulnerabilidades de lógica de negocio. js-project-nightowl ya muestra que una estructura similar a la de una aplicación cambia el comportamiento del modelo.

El análisis de recurrencia usa firmas de hallazgos normalizadas. En los gráficos de hallazgos no coincidentes de cada modelo, la firma consta de tarea + tipo de vulnerabilidad + archivo + línea, agrupados por separado para cada configuración de modelo. Las distintas opciones de normalización cambian los porcentajes exactos; por eso la firma se incluye en la entrega de los gráficos y en las notas de reproducibilidad.

Siguiente paso: fixtures más amplios y flujos de trabajo que combinan LLM y SAST

La próxima versión de Snyk VulnBench debería ir más allá de los fragmentos pequeños e independientes. Planeamos agregar estructuras de aplicaciones más completas, vulnerabilidades identificadas por LLM, lógica de negocio y categorías BOLA, además de una fuente independiente de verdad de referencia, como los datos de referencia al estilo de BaxBench.

También deberíamos separar las líneas del benchmark. Una puede seguir midiendo la coincidencia con Snyk Code para comparar el comportamiento de los modelos con una referencia determinista de SAST. Otra debería usar una verdad de referencia independiente y revisable externamente, para que los resultados principales no dependan de los hallazgos de Snyk.

Por último, los informes futuros deberían evaluar flujos de trabajo combinados: revisión solo con modelos, análisis solo con SAST y revisión con LLM complementada con contexto de SAST. Los datos de JS 1.0 ya apuntan en esa dirección. Los modelos y SAST no fallan de la misma manera. Por eso conviene combinarlos.