← Volver a la clasificación

Cómo realizamos las pruebas

La calidad de las pruebas de rendimiento depende en gran medida de cómo se configuren. A continuación explicamos cómo evaluamos si un modelo es capaz de detectar vulnerabilidades reales y cuánto cuesta.

1. 1

   Elige vulnerabilidades reales

   Extraemos los CVE conocidos de la base de datos de avisos de GitHub, que abarca numerosos lenguajes y tipos de proyectos.

2. 2

   Marca como vulnerable esa confirmación

   Cada repositorio se extrae en un commit realizado justo antes de que se corrigiera.

3. 3

   Ejecutar dentro del entorno de producción

   Los modelos se ejecutan dentro del mismo entorno de IA que incluimos con Code Security Audit y Aikido Attack.

4. 4

   Señala el fragmento de código vulnerable

   Como sabemos dónde se encuentra cada vulnerabilidad, los agentes de investigación se centran en el código vulnerable. Un fallo se debe a un error de razonamiento, no a un desperdicio de presupuesto por buscar en la parte equivocada del repositorio. Las indicaciones son breves y independientes del modelo.

5. 5

   Ejecútalo tres veces y, a continuación, agrupa los resultados

   Los modelos son no deterministas. Ejecutamos cada uno de ellos tres veces y consideramos que se ha encontrado un CVE si aparece en cualquiera de las ejecuciones. La combinación de resultados permite detectar errores que se pasarían por alto en una sola ejecución, y es un reflejo más realista de cómo se implementarían estos agentes.

6. 6

   Ten en cuenta tanto la cobertura como el coste

   Registramos cuántas vulnerabilidades CVE redescubre cada modelo y cuánto ha costado lograrlo, ya que el modelo más potente rara vez es el que ofrece la mejor relación calidad-precio. También comparamos los niveles de razonamiento cuando el proveedor los facilita.

---

Acerca de la configuración del arnés

Un «harness» es lo que convierte un modelo de lenguaje en un auditor. Un asistente de programación de uso general está diseñado para una tarea diferente: tomar una tarea y generar código que funcione. Si se le indica un repositorio y se le pregunta si es seguro, se comporta como un desarrollador que revisa el código en busca de algo que esté claramente mal, y se detiene en cuanto encuentra algo plausible. La auditoría de seguridad de código de Aikido está diseñada de forma diferente. Explora el código en busca de posibles puntos de entrada, investiga en profundidad cada flujo sospechoso y, a continuación, clasifica los resultados para que solo obtengamos vulnerabilidades reales.

Como sabíamos dónde residía cada vulnerabilidad, dirigimos a cada agente investigador directamente al fragmento de código vulnerable. De esa manera, un fallo refleja un problema de razonamiento en lugar de un presupuesto desperdiciado al deambular por la parte incorrecta de la base de código. El modelo aún tiene que entender el flujo, juzgar la explotabilidad y reportarlo correctamente. Las indicaciones se mantuvieron cortas y agnósticas al modelo para que ningún proveedor se viera favorecido por la redacción.

---