Prueba de aceptación de revisión de seguridad con IA: lo que Aave V3 y V4 enseñan sobre la priorización de escáneres de contratos inteligentes

Empieza con la restricción poco vistosa. Un escáner de seguridad con IA puede producir una lista segura de alertas en minutos. Un responsable de seguridad todavía tiene que decidir qué alertas son reales, cuáles son duplicados, cuáles se pueden reproducir y cuáles merecen tiempo de revisión esta semana.

Por eso la revisión asistida por IA de Aave sobre Aave V3 y V4 resulta más útil como prueba de flujo de trabajo que como titular de victoria. Aave Labs informó 71 hallazgos totales en tres herramientas de seguridad con IA anonimizadas. La revisión manual aceptó 20. El artículo de Aave dice que los hallazgos aceptados fueron bajos o informativos, mientras que varias alertas que llegaron como críticas o altas se trataron después como falsos positivos tras la validación humana.

Esos números son interesantes. También son fáciles de usar mal. Son resultados comunicados por el proyecto a partir de un alcance y un método definidos. No prueban que un protocolo, repositorio o lanzamiento sea seguro. Muestran algo más estrecho y más operativo: la salida del escáner necesita una prueba de aceptación antes de que se le permita dar forma al traspaso de auditoría, la política de CI o las decisiones de lanzamiento a producción.

La misma idea se aplica fuera de los contratos inteligentes. Las revisiones de seguridad de aplicaciones, las comprobaciones de API, los escaneos de políticas de infraestructura y la revisión de código habilitada por IA se encuentran con el mismo problema. Una herramienta que suena segura todavía puede equivocarse sobre alcanzabilidad, supuestos de roles, impacto o causa raíz duplicada. Optijara ha usado el mismo patrón de puerta de aceptación para la calificación local de VLM, la reproducibilidad del algoritmo de X y la infraestructura de IA sensible a la latencia. Los escáneres de seguridad deberían enfrentarse a la misma disciplina.

Mi opinión es directa: un escáner ruidoso no es un control de seguridad. Es una fuente de pistas. Se convierte en control solo después de que el equipo puede reproducir sus entradas, normalizar sus hallazgos, calibrar la severidad y registrar decisiones humanas.

Por qué la revisión asistida por IA de Aave es una prueba de reproducibilidad, no una vuelta de victoria

Aave informó que tres herramientas de seguridad con IA se ejecutaron contra los repositorios de producción de Aave V3 y Aave V4. Los escaneos cubrieron los árboles src completos en commits fijados. Cuando las herramientas lo admitían, recibieron un contexto similar al que recibirían los auditores humanos, incluido contexto de modelo de amenazas y auditoría.

Aave también describió pruebas de mutación en cuatro contratos de V4, Hub, Spoke, TreasurySpoke y AaveOracle. La prueba usó 304 mutaciones deliberadas. Las pruebas existentes mataron 271, mientras que 33 fueron inconclusas porque las suites de pruebas agotaron el tiempo de espera.

El titular fue 71 hallazgos expuestos y 20 aceptados tras revisión manual. La mejor lección está en el filtrado. Aave dice que los hallazgos se clasificaron manualmente como válidos, falsos positivos, duplicados o por diseño. Ahí es donde vive la operación de revisión.

Un escáner que emite 71 alertas no es automáticamente más fuerte que uno que emite menos. El volumen puede significar cobertura. También puede significar causas raíz repetidas, contexto débil, supuestos obsoletos o explicaciones generadas alrededor de rutas de código que no importan. La pregunta para un gestor de seguridad es más precisa: después de la normalización, la deduplicación, la revisión de severidad y la adjudicación humana, ¿qué queda?

La ausencia de hallazgos críticos o altos confirmados en este alcance comunicado no debe leerse como prueba de seguridad. Significa que esos hallazgos no se confirmaron bajo el estado de código, el comportamiento de herramientas, el método de revisión y el proceso de clasificación humana comunicados. Eso sigue siendo evidencia útil. No sustituye al modelado de amenazas, las auditorías independientes, la verificación formal, los concursos, la monitorización, la planificación de respuesta a incidentes ni los controles de lanzamiento.

La línea base de evidencia: fijar fuente, commit, herramienta y método

La primera puerta de AISRAT es la fidelidad del artefacto. Antes de que alguien debata la severidad, el equipo necesita un paquete de evidencia que fije el objetivo exacto de la revisión. Como mínimo, registra la URL del repositorio fuente, el hash de commit, los lockfiles de dependencias, las versiones del compilador, el contenedor de compilación, la configuración del escáner, los tiempos de espera, los permisos, los informes generados, las rutas excluidas y las notas de los revisores.

El artículo de Aave dice que los escaneos se ejecutaron contra commits fijados de repositorios de producción y cubrieron árboles de código fuente. Los repositorios públicos de Aave V3 Origin y Aave V4 muestran código, auditorías, informes, pruebas, scripts y directorios de documentación relevantes. Eso da a los lectores contexto útil, pero una prueba de aceptación interna necesita más que contexto.

El equipo debería poder reconstruir el objetivo desde un entorno limpio y reproducir la entrada del escáner. Si el artefacto escaneado no se puede reconstruir, la revisión de severidad ya está en terreno débil. El alcance del repositorio no es lo mismo que el alcance del código revisado. Un repositorio puede contener src, pruebas, scripts, documentación, archivos generados, módulos obsoletos, adaptadores y paquetes periféricos. Cada uno puede afectar el volumen de alertas y la carga de los revisores.

Los escáneres asistidos por IA también pueden cambiar la salida cuando cambia un modelo, prompt, conjunto de reglas, fuente de recuperación, versión del detector o tiempo de espera. Los proveedores no siempre expondrán cada detalle interno. Registra lo que puedas ver: versión del producto, marca temporal del informe, archivo de configuración, plantilla de prompt si se usa, instantánea de documentación, línea de comandos, parámetros de API y variables de entorno que afectan la salida.

El estándar no es la reproducibilidad académica. El estándar es una reproducibilidad operativa suficiente para decidir si el escáner pertenece a una ruta que afecta colas de revisores, puertas de CI, paquetes de auditoría o decisiones de lanzamiento.

El marco AISRAT

AISRAT significa prueba de aceptación de revisión de seguridad con IA de Optijara. Es un marco de decisión de seis capas para decidir dónde encaja un escáner de IA en una ruta de revisión de contratos inteligentes o seguridad de aplicaciones.

La fidelidad del artefacto comprueba que el escáner revisó el código que importa al equipo. Los campos requeridos incluyen repositorio, commit, comando de compilación, compilador, locks de dependencias, imagen de contenedor, ruta de código fuente, artefactos generados, archivos excluidos, versión de herramienta, versión de modelo o conjunto de reglas cuando esté disponible y permisos. Para contratos inteligentes, añade versión del compilador, supuestos de cadena, configuración de despliegue, dependencias simuladas y pruebas necesarias para reproducir el comportamiento.

La normalización de problemas hace que la salida del escáner sea comparable antes de que los revisores le dediquen tiempo. Normaliza cada alerta en archivo, función, ruta de código, clase de vulnerabilidad, precondiciones, afirmación de explotabilidad, evidencia, confianza, grupo duplicado, severidad propuesta, estado de remediación y notas del revisor. Una narrativa larga no merece peso extra solo porque parece autoritaria.

La severidad es una afirmación. No es evidencia. AISRAT exige un argumento de explotabilidad o impacto que encaje con el modelo de confianza del sistema. En el artículo de Aave, la validación humana rebajó o rechazó alertas que llegaron con etiquetas críticas o altas. La herramienta propone severidad. El revisor la calibra contra estado alcanzable, supuestos de roles, impacto, ruta de código y modo de fallo.

La adjudicación del revisor necesita estructura. Cuando sea práctico, oculta a los revisores la identidad de la herramienta durante la primera pasada. Registra decisiones de aceptado, rechazado, duplicado, por diseño, no respaldado y ruta de código alucinada. Incluye muestreo de falsos positivos y muestreo de falsos negativos contra vulnerabilidades conocidas, hallazgos de auditoría históricos, pruebas de mutación o suites de bugs sembrados.

La economía de la accionabilidad decide si la adopción vale el coste. Mide tiempo hasta la primera priorización, tiempo hasta la adjudicación, minutos de revisor por hallazgo aceptado, carga de duplicados, hallazgos reabiertos y coste por hallazgo accionable aceptado. Luego define qué sucede después de la aceptación: umbrales de CI, anulación humana, paquetes de traspaso a auditoría, flujo de divulgación, control de acceso, telemetría, canarios, criterios de reversión y pruebas de regresión.

{
  "framework": "AISRAT",
  "minimumEvidence": ["repo", "commit", "build", "toolConfig", "normalizedFinding", "reviewerDecision"],
  "routeOptions": ["research", "triageAssistant", "ciSignal", "auditInput"],
  "acceptanceQuestion": "¿Produce el escáner hallazgos reproducibles, respaldados por evidencia y no duplicados a un coste aceptable de revisión para esta ruta?"
}

Matriz de decisión de ruta

Un escáner con ideas útiles pero reproducibilidad débil aún puede pertenecer a la ruta de investigación. Una puerta de CI necesita un listón más alto porque puede ralentizar la entrega o crear falsa confianza. La entrada para auditoría formal necesita el paquete de evidencia más limpio porque los auditores deberían poder inspeccionar las decisiones aceptadas y rechazadas, no solo la lista final de defectos.

Lista de comprobación de implementación de AISRAT

Para contratos inteligentes, añade compilación de contratos, supuestos de despliegue, roles de gobernanza, dependencias de oráculos, funciones privilegiadas, supuestos de mensajería entre cadenas y pruebas de invariantes o fuzzing. Para seguridad de aplicaciones, añade versiones de servicios, esquemas de API, flujos de identidad, clasificación de datos, paridad de entornos y estado del grafo de dependencias.

Errores comunes

El conteo de alertas es el número más fácil de vender y el número más débil para operar. Recompensa herramientas verbosas y castiga herramientas que suprimen la salida de baja confianza. La mejor medida son los hallazgos accionables aceptados después de la normalización, la deduplicación y la adjudicación del revisor.

Una etiqueta crítica sin una ruta ejecutable o revisable no es una vulnerabilidad crítica. AISRAT pide a los revisores separar la clase de vulnerabilidad de la evidencia de explotabilidad, el estado alcanzable, los supuestos de roles y el impacto. Esto importa en sistemas con roles de gobernanza, timelocks, supuestos de oráculos y comportamiento de reversión deliberado.

Los duplicados consumen tiempo de revisión. Archivos alucinados, rutas inalcanzables, funciones de framework no respaldadas, dependencias obsoletas y objetivos que no compilan pueden hacer que un escáner parezca productivo mientras aporta poco valor de seguridad. Haz seguimiento de estas categorías por separado. Las alucinaciones rechazadas deberían convertirse en ejemplos de regresión para que la misma herramienta no las devuelva como problemas nuevos.

Los falsos positivos son fáciles de ver porque los revisores los tienen delante. Los falsos negativos requieren pruebas deliberadas. Usa vulnerabilidades conocidas, problemas de auditoría históricos, pruebas de mutación, suites de bugs sembrados y líneas base convencionales de análisis estático. Un escáner con menos falsos positivos puede seguir siendo una mala señal de CI si omite problemas conocidos.

Plan de medición

Compara la ruta asistida por IA con una línea base usando el mismo artefacto fijado y el mismo modelo de amenazas. La línea base podría ser revisión solo humana, análisis estático convencional o el conjunto de escáneres existente del equipo. Los objetivos universales de precisión suelen ser perezosos. Lenguaje, framework, madurez del código, calidad del contexto y modelo de amenazas cambian todos el nivel aceptable de ruido.

Empieza con un piloto acotado: un repositorio, un commit, un modelo de amenazas, una ruta. Decide si el escáner merece ser ayuda de investigación, asistente de priorización, señal de CI o entrada de auditoría. Amplía solo después de que el paquete de evidencia sea lo bastante bueno para que alguien fuera del equipo inmediato lo inspeccione.

La revisión de Aave es útil porque muestra la brecha entre la severidad del escáner y la evidencia confirmada por humanos. AISRAT convierte esa brecha en un sistema de gestión. Protege a los revisores del ruido, da a los proveedores comentarios concretos y ayuda a los equipos a adoptar revisión de seguridad asistida por IA sin fingir que la herramienta se ha convertido en el auditor. Si tu equipo está diseñando una ruta de revisión asistida por IA, Optijara puede ayudar a definir las puertas de aceptación, el plan de medición y los controles de gobernanza antes de que el escáner empiece a influir en decisiones de producción.