secprbench/secprbenchEvaluación comparativa de 265 cambios de código reales que introducen vulnerabilidades en nueve proyectos de C, C++ y Rust, con tareas de revisión emparejadas, sandbox de Docker, juez y arnés de evaluación.
SecPRBench evalúa si un revisor de código encuentra el fallo de seguridad en un cambio real. Cada caso es el cambio upstream que introdujo una vulnerabilidad en uno de nueve proyectos en C, C++ y Rust. El revisor recibe el diff, el mensaje de commit y una instantánea del código fuente sin historial de Git utilizable, pero sin descripción de la vulnerabilidad, y debe identificar el fallo y explicar su causa raíz. Una tarea complementaria muestra el cambio reparado en la revisión de corrección upstream.
Este repositorio contiene los datos del benchmark y el arnés de evaluación: 265 casos / 530 tareas de revisión emparejadas, evidencia de referencia privada para el evaluador, el sandbox de revisión Docker, el juez basado primero en criterios y los resultados congelados reportados en el artículo. El pipeline de construcción que recopiló y verificó los casos no forma parte de este repositorio. Los resultados y las trayectorias de revisión guardadas se pueden consultar en el sitio web de resultados.
| Proyecto | Casos | Tareas |
|---|---|---|
| curl | 26 | 52 |
| FFmpeg | 61 | 122 |
| Firefox | 27 | 54 |
| FreeType | 15 | 30 |
| OpenSSL | 29 | 58 |
| Redis | 16 | 32 |
| SQLite | 33 | 66 |
| V8 | 44 | 88 |
| Wasmtime | 14 | 28 |
| Total | 265 | 530 |
Las introducciones más antiguas siguen siendo elegibles; no hay una fecha límite de introducción. Lea la ficha de datos y los problemas conocidos antes de interpretar los resultados.
Se requiere Python 3.10 o superior; los ejemplos usan Python 3.11. La instalación de dependencias utiliza la red. Las comprobaciones en sí no necesitan Docker, credenciales ni llamadas a modelos.
python3.11 tools/check_release.py --root .
python3.11 tools/bundle_verification.py --check
python3.11 -m venv .venv
.venv/bin/pip install -e '.[test]'
.venv/bin/python -m pytest -q -m 'not integration and not docker and not live'
.venv/bin/secprbench --help
El validador de la release comprueba el roster, los hashes exactos de tareas y evidencias, la consistencia del índice, las identidades excluidas, los recuentos emparejados y los resultados congelados. Los problemas retenidos conocidos se informan por separado de los fallos de integridad. Una comprobación offline superada no significa que todas las vulnerabilidades hayan sido reconstruidas y reproducidas.
El ejemplo de contrato se ejecuta sin un modelo ni Docker y demuestra el formato de predicción público. Para implementar un escáner real:
.venv/bin/secprbench harness scaffold my_scanner --output .work/harnesses
Para la preparación de fuentes, la revisión aislada en Docker, la evaluación y la generación de informes, siga el
recorrido de evaluación. El ejecutor utiliza
data/roster.json --data-root data. La evaluación respaldada por modelos requiere sus propias
credenciales de proveedor y utiliza los recursos del proveedor elegido.
data/roster.json: lista canónica de ejecución emparejada, con
rutas de tareas relativas a data/ y hashes de los bytes originales de las tareas.instances/: un JSONL por proyecto más un índice global para
un acceso cómodo a casos y tareas. Estos archivos contienen etiquetas privadas y no deben
montarse en un contenedor de revisión.provenance/: hashes de origen, política de elegibilidad, nueve decisiones
de exclusión y problemas retenidos para seguimiento.artifacts/results/: los resultados congelados del artículo para 265 casos
correspondientes a ocho configuraciones de revisor directas, con recuentos derivados.verification/: entradas de prueba de concepto incluidas, registros de
reproducción y un manifiesto de cobertura. Consulte verification.El juez que prioriza los criterios acredita el fallo causal especificado solo cuando está presente en la instantánea evaluada. Cero veredictos positivos de acompañamiento no establecen cero falsas alarmas. Los acompañamientos históricos utilizan la instantánea de corrección upstream para la revisión, mientras que la verificación puede usar un árbol reparado compuesto. Esas identidades se conservan y no deben confundirse. Consulte scoring y protocol.