Prueba las afirmaciones de seguridad de tu agente de código en tu repo

Tu agente de código puede encontrar un bug, corregirlo y decirte que el repo está seguro. Si no puede demostrar un flujo de trabajo reproducible, aislado en sandbox y verificado manualmente en tu repo, sus afirmaciones de seguridad son marketing.

Mantis es un marco de código abierto vinculado a la práctica interna de Google para la detección de bugs. No es un producto oficial de Google. Mantis está limitado a uso de demostración y no debe desplegarse en entornos de producción en vivo. Eso lo convierte en un caso de prueba útil, no en una dependencia de producción.

El arnés convierte una promesa vaga en una revisión medible: encontrar un problema real, demostrarlo, corregirlo de forma segura y dejar evidencia que un humano pueda auditar.

Haz que la prueba sea lo suficientemente aburrida para repetirla

Usa el mismo repo, la misma rama, el mismo objetivo y la misma puntuación. Si el agente cambia las reglas a mitad de ejecución, el resultado no es comparable. Un buen arnés hace que el agente declare cuándo no puede ejecutar un comando, cuándo falta una prueba y cuándo un hallazgo necesita un humano.

Ejecuta las cinco puertas antes de confiar en una corrección

• Valida el preflight antes de que el agente toque el código. Confirma que el repo compila, que las pruebas se ejecutan y que no hay secretos. Dale al agente una rama acotada, un objetivo claro de archivo o directorio y un comando de prueba que pueda ejecutar. Registra los comandos exactos, no solo el resultado. Si la línea base falla, corrígela primero para que el agente dedique su esfuerzo al objetivo. Detente cuando el commit de línea base esté limpio, el comando de prueba local pase y tengas una nota breve sobre el alcance de acceso del agente.
• Detecta capacidades en lugar de asumirlas. Pide al agente que lea, edite, ejecute pruebas y aísle cambios. Una comprobación de capacidades útil incluye si el agente puede crear una rama descartable, ejecutar una prueba dirigida y detenerse cuando se lo indiquen. Si no puede ejecutar un sandbox, anota esa limitación antes de juzgar su salida. Mantén una lista breve de capacidades: lo que puede hacer, lo que no puede y lo que verificarás manualmente.
• Ejecuta una campaña contra un archivo o directorio. No empieces con el monorepo completo. Elige un módulo con rutas conocidas, cambios recientes o una superficie sensible a la seguridad. Haz que el objetivo sea lo suficientemente pequeño para que un humano pueda leer cada archivo modificado. Como ejemplo práctico, la técnica de árbol jerárquico de resumen de seguridad de Mantis redujo la sobrecarga de tokens en más de un 85 por ciento. La puerta se cierra con una lista de hallazgos acotada, no con una avalancha de avisos genéricos.
• Lee la tasa de verdaderos positivos, no el número de hallazgos. Cuenta solo los hallazgos que sobreviven a la reproducción y la revisión de expertos. Un escaneo de código con IA descuidado puede producir tasas de verdaderos positivos por debajo del 7 por ciento. Si el denominador está oculto, la puntuación no es útil. Cierra la puerta solo con una proporción visible: verdaderos positivos verificados divididos por el total de hallazgos.
• Reproduce antes de corregir, luego aísla en sandbox y verifica manualmente. Exige un guion de reproducción o una prueba antes de que el agente proponga un parche. Trata la corrección en sandbox como una etapa separada: pon el parche en un entorno descartable y ejecuta las pruebas relevantes. Mantén el parche y la reproducción en commits separados y revisables. Los hallazgos de Mantis requieren verificación manual por un experto en seguridad antes de ser reportados. Termina con un parche que tenga una reproducción, un resultado de sandbox y una aprobación humana.

Mantén el veredicto honesto cuando la evidencia sea confusa

El fallo común es tratar un parche confiado como prueba. El agente puede producir un diff plausible, una prueba que pasa y un resumen sencillo. Nada de eso demuestra que la vulnerabilidad existiera, que el parche la corrija o que la corrección no abra una nueva vía.

En Mantis, una reproducción automática fallida de una vulnerabilidad no demuestra que sea un falso positivo, y una reproducción exitosa no garantiza que sea explotable en todos los contextos. El arnés necesita una etapa de juicio humano. El experto decide si el hallazgo importa, si la reproducción es representativa y si el parche es lo suficientemente seguro para publicarse.

Escribe el veredicto en una nota breve: qué se encontró, qué se reprodujo, qué se verificó. Si alguna línea está vacía, el agente no ha terminado. Un parche que pasa las pruebas pero no puede vincularse a una vulnerabilidad específica es un cambio, no una corrección de seguridad.

Un hallazgo que no puede reproducirse es una pista, no un resultado. Usa el arnés para comparar agentes, no para reemplazar la revisión. Un buen resultado es un conjunto pequeño de problemas verificados, una ruta de reproducción limpia y un parche que sobrevive a las pruebas en sandbox. Si el agente no puede producir eso, marca la afirmación de revisión de seguridad como no verificada.