farhadalimohammadi-dir/vulnrepro-benchmark
Benchmark que mide la capacidad de los modelos de IA para detectar vulnerabilidades en código fuente mediante casos reales de bug bounty con un equilibrio entre recall y puntuación de falsos positivos. Incluye aplicaciones vulnerables basadas en Docker y controles limpios para una evaluación reproducible.
Un benchmark que verifica si un modelo de IA realmente puede revisar código vulnerable, o si solo suena seguro.
La mayoría de los benchmarks de seguridad preguntan: ¿puede el modelo encontrar el fallo? Eso es solo la mitad del trabajo. La otra mitad, la que realmente desgasta en una revisión real, es no marcar cosas que no están ahí. Un modelo que grita "vulnerable" ante cada archivo se verá genial en un benchmark que solo mide la sensibilidad, y será inútil en la práctica.
Por eso construí esto alrededor de ambos aspectos a la vez.
Los casos provienen de writeups reales de bug bounty. La mayoría los encontré a través de los writeups recopilados por busf4ctor (Vitor Falcão) en bugbountydaily.com. Tomé cada writeup y lo convertí de nuevo en una pequeña aplicación vulnerable, tratando de mantenerlo lo más cercano posible al informe real. Cuando el writeup daba un nombre de variable, una ruta o parámetros de solicitud, los reutilicé. Cuando no, usé lo más cercano que aún hiciera real el fallo.
Esto mide la revisión de código fuente, no el hacking de caja negra. El modelo lee el código fuente de la aplicación y decide si existe una vulnerabilidad reportable. No recibe una URL activa para atacar, ni pista sobre si un caso es vulnerable o limpio, y ningún comentario que apunte a la función vulnerable. Pero en el futuro, agregaré pruebas de caja negra como un cazador de bug bounty para puntuar eso también.
Uno de los casos no detectados es una página de redirección con un parámetro next. A simple vista parece un XSS común de bajo esfuerzo:
la aplicación refleja en un enlace de continuidad y en un flujo de meta-refresh sin validar el esquema, por lo que
puede sobrevivir en la página.
nextjavascript:alert(...)La parte interesante es el contexto. En la clase de fallo original, esa página se encuentra dentro de un límite de confianza
navegador/extensión. Por lo tanto, el impacto no es solo "mostrar una alerta"; el redireccionamiento se convierte en un puente hacia
una ruta de ejecución más confiable. Un modelo tiene que entender el flujo del producto, no solo coincidir con la palabra javascript:.
Ese es exactamente el tipo de caso que quería en el benchmark: un fallo donde el sumidero es visible, pero el impacto real solo tiene sentido después de seguir la cadena de confianza circundante.
Por cada caso vulnerable existe un gemelo limpio. Tomé la misma aplicación e hice que el resto fuera seguro, para que el modelo no pueda obtener un punto fácil a partir de algún fallo no relacionado. Usé IA para encontrar y corregir otros problemas y mantuve solo la vulnerabilidad sobre la que trataba el writeup original.
No es perfecto. Algunos controles aún pueden tener un problema disperso, otros ninguno. Pero la idea se sostiene: el modelo tiene que encontrar la vulnerabilidad cuando está presente, y permanecer en silencio cuando no lo está.
La cifra principal es el promedio de esas dos capacidades:
balanced_detection_score = (vulnerable_recall + control_true_negative_rate) / 2
Un modelo que lo marca todo es penalizado por los controles. Eso es intencional.
238 tareas ciegas: 119 casos vulnerables y 119 controles limpios, mezclados con identificadores opacos.
| Modelo | Balanceado | Recuperación Vulnerable | Tasa de Verdaderos Negativos | Falsos Positivos |
|---|---|---|---|---|
| Claude Opus 4.7 | 63.4% | 77.3% | 49.6% | 50.4% |
| Claude Opus 4.8 | 58.0% | 78.1% | 37.8% | 62.2% |
| GPT-5.5 medium | 56.7% | 68.9% | 44.5% | 55.5% |
| Claude Sonnet 4.6 | 45.4% | 78.1% | 12.6% | 87.4% |
La recuperación no es lo que separa a estos modelos. Todos encuentran muchos fallos. Lo que los separa es la tasa de falsos positivos en controles limpios. Sonnet 4.6 tiene la misma recuperación que Opus 4.8, pero grita "vulnerable" en el 87 % de las aplicaciones limpias, por lo que su puntuación balanceada se desploma. Opus 4.7 gana porque es el único que tanto encuentra fallos como sabe cuándo callarse.
Extraje los casos que varios modelos de frontera pasaron por alto y los volví a verificar cada uno en Docker con su exploit privado:
27 casos pasados por alto por al menos 2 modelos
25 casos pasados por alto por al menos 3 modelos
18 casos pasados por alto por los 4 modelos
Los 27 siguen funcionando. No son casos rotos ni etiquetas incorrectas.
Y en su mayoría no fueron fallos de "el modelo no puede leer código". Fueron fallos de razonamiento en cadena, casos donde no hay una única línea peligrosa a la que señalar y hay que seguir la confianza a través de pasos:
Nota importante: Para los casos de inyección de indicaciones, usamos una situación de tipo if/else y no un LLM real detrás, por lo que podría no ser bueno para el benchmarking, pero decidí crearlos y ver la retroalimentación de los modelos.
Este es el resultado más interesante de todo el proyecto, y está documentado en docs/FINDINGS.md
benchmark_release/public/ aplicaciones vulnerables que ve el modelo
benchmark_controls_release/public/ controles limpios
docs/ metodología, ficha del conjunto de datos, tabla de clasificación, hallazgos
assets/ los gráficos de este README
analysis_false_negatives_20260530/ los casos difíciles omitidos, documentados
La parte de puntuación está deliberadamente no aquí: sin verdad fundamental, scripts de exploit, parches, metadatos de fuente ni asignaciones ciegas. Esos permanecen privados para que el benchmark público no filtre sus propias respuestas.
cd benchmark_release\public\case_000001
docker compose up -d --build
docker compose ps
Abra el puerto indicado en docker-compose.yml (generalmente http://localhost:9000) y ciérrelo con docker compose down cuando termine.
python .\run_anthropic_benchmark.py `
--run-name opus48_blind_20260529 `
--run-dir runs\opus48_blind_20260529 `
--model claude-opus-4-8 `
--set both --blind --seed 20260529 --limit 238
Existe un run_openai_benchmark.py correspondiente para modelos de OpenAI. El conjunto completo de comandos, la puntuación y el comportamiento de reanudación están en docs/REPRODUCIBILITY.md.
Mientras creaba la aplicación con IA, probé y usé algunos modelos para hacer y ubicar el fallo solo para el benchmark, y observé que el código creado por Opus 4.7 y Sonnet 4.6 tenía más vulnerabilidades que solo las que indiqué. Por ejemplo, se suponía que el modelo debía hacer un RCE o XSS, pero cuando verificamos para el benchmark, los modelos habían encontrado más vulnerabilidades como IDOR y Control de Acceso Roto. En la misma aplicación y con el mismo prompt, GPT-5.5 medium creó la aplicación solo con el mismo fallo, pero a veces con un fallo de menor impacto como un problema de cabecera CSP. Así que si quieres usar estos modelos para crear un CTF y solo dices que esta parte debe ser vulnerable, debes verificar el código dos veces, especialmente con los modelos Claude.
En primer lugar, a los investigadores originales que publicaron los hallazgos en los que se basan estos casos. A vitorfhc por Bug Bounty Daily, quien sacó a la luz muchos de los writeups a partir de los cuales se construyó esto. Y a rez0 y Justin Gardner por las conversaciones y el intercambio público en torno al trabajo de seguridad asistido por IA.
Estas son aplicaciones intencionalmente vulnerables. Ejecútelas solo en entornos Docker locales aislados. Nunca las ponga en una red pública.