Mantis: agentes de IA para detectar y corregir vulnerabilidades de código

La inteligencia artificial rápidamente se mudó a las herramientas de los desarrolladores. Generación de código, documentación, pruebas, refactorización o búsqueda de una base de datos: ya hay muchos usos. Con Mantis, Google empuja esta lógica en otra dirección utilizando varios agentes especializados de IA para participar en la búsqueda de vulnerabilidades, su verificación y la preparación de parches.

Publicado en código abierto, Mantis se presenta como un marco diseñado para automatizar varios pasos en el análisis de seguridad de un repositorio: descubrimiento, clasificación, reproducción y corrección de vulnerabilidades. Por lo tanto, el enfoque no es sólo pedir un modelo para leer algunos archivos y reportar lo que cree que es sospechoso. Busca construir un proceso real alrededor de IA.

Este desarrollo es particularmente interesante para los equipos que desarrollan SaaS, aplicaciones web y software empresarial. Muestra cómo la IA podría participar gradualmente no sólo en la creación del código, sino también en su control y mantenimiento.

1. ¿Qué es Mantis?

Mantis es un conjunto de herramientas de código abierto diseñado para trabajar con agentes de desarrollo que pueden trabajar directamente sobre una base de código. Google resume su objetivo alrededor de cuatro pasos principales: descubrir, ordenar, reproducir y corregir vulnerabilidades de software.

El proyecto forma parte de un enfoque más amplio utilizado por Google Cloud para integrar agentes especializados en diferentes etapas del ciclo de desarrollo de software. Google indica que tiene una versión más completa del sistema, mientras que los elementos publicados permiten experimentar con los conceptos principales.

El objetivo no es simplemente crear un nuevo escáner de seguridad. Más bien, la idea es orquestar varios agentes capaces de distribuir el trabajo y transmitir sus hallazgos a los próximos pasos. Un oficial puede explorar el repositorio, otro puede buscar comportamiento potencialmente peligroso, un tercero puede cuestionar el resultado, y otro puede intentar replicar el problema. Por último, se puede generar y presentar una propuesta de corrección para su validación.

Esta organización acerca a Mantis a un proceso automatizado de revisión de seguridad que un simple asistente de conversación. El valor proviene no sólo del modelo utilizado, sino de cómo se encadenan tareas, controles y pruebas.

2. Por qué un simple LLM no es suficiente para analizar la seguridad de un proyecto

Los modelos de lenguaje modernos entienden el código relativamente bien. Pueden explicar una función, identificar errores obvios o proponer mejoras. Pero esta capacidad tiene un límite importante: un modelo puede producir una respuesta muy convincente mientras se equivoca.

En un uso clásico, un error puede ser embarazoso. En un análisis de seguridad, puede ser problemático. Un modelo puede anunciar que existe una vulnerabilidad mientras que el problema ya está neutralizado en otra parte de la aplicación. Por el contrario, puede perder un control importante ubicado en otro archivo. También puede proponer una corrección que parece lógica en aislamiento pero no respeta el funcionamiento general de la aplicación.

Google explica que algunos enfoques demasiado simples para el análisis de código por IA pueden resultar en tasas positivas reales por debajo del 7%. Este es precisamente uno de los problemas que Mantis busca abordar. Un gran número de alertas no necesariamente significan una mejor seguridad: un equipo puede perder tiempo comprobando docenas de resultados que en última instancia no plantean ningún riesgo real.

Así que la pregunta importante no es sólo "¿puede IIA encontrar algo sospechoso?", sino más bien "¿Puedo explicar por qué este problema es importante y traer suficientes elementos para verificarlo?" En seguridad, una alerta útil debe ser contextualizada, reproducible y comprensible.

3. Varios agentes de inteligencia en lugar de uno

Mantis se basa en particular en un enfoque multiagente. En lugar de confiar todo el análisis a un solo modelo con una instrucción muy general, se encadenan varias tareas especializadas. En la arquitectura descrita por Google, un agente de estrategia puede comenzar examinando la estructura general del proyecto, dependencias y áreas potencialmente sensibles.

Los agentes de investigación luego exploran el código fuente con más precisión. Otros pasos se utilizan para consolidar descubrimientos, eliminar duplicados, verificar resultados y filtrar problemas increibles. Esta separación tiene un interés importante: un agente que simultáneamente se le pide que entienda varios miles de archivos, que busque vulnerabilidades, que revise sus propias conclusiones y que proponga correcciones debe resolver demasiados problemas a la vez.

Una arquitectura especializada le permite cortar el trabajo. También permite a algunos oficiales impugnar las conclusiones de otros. Este principio es común en el desarrollo del software humano: una persona escribe código, otra lo lee y prueba entonces comprobar su comportamiento. Mantis aplica una lógica comparable a los agentes de IA.

4. Comprender el contexto de un repositorio de código

Una vulnerabilidad casi nunca existe sólo porque una línea de código parece extraña. El contexto es muy importante. Una función puede parecer vulnerable cuando se analiza solo mientras se realiza un cheque antes en la aplicación. Por el contrario, varios componentes perfectamente legítimos tomados por separado pueden ser peligrosos cuando se combinan.

Por esta razón, Mantis busca construir una representación más general del proyecto. Google afirma que el marco analiza la historia del repositorio con el fin de aprender de los arreglos de seguridad anteriores y construir gradualmente documentación sobre el modelo de arquitectura y amenaza.

Para limitar la cantidad de información enviada simultáneamente a los modelos, Mantis también utiliza una organización jerárquica de contexto. Los archivos se pueden resumir a nivel de sus carpetas, entonces esta información se condensa para obtener una visión global del repositorio. Google afirma que esta técnica ha reducido la cantidad de contexto necesaria por más del 85% mientras conserva información estructural útil.

Esta idea va más allá de la ciberseguridad. En muchos proyectos utilizando IA, el problema no es simplemente enviar más información al modelo. Sobre todo, debe darse el contexto adecuado en el momento adecuado. Documentación clara, historia comprensible y arquitectura legible se vuelven útiles para los desarrolladores y agentes por igual.

5. Reproducción de vulnerabilidades en un entorno aislado

Una vulnerabilidad detectada por la IA no se considera automáticamente verdadera. El marco proporciona medidas para tratar de reproducir el comportamiento en un entorno aislado. El objetivo es pasar de una hipótesis — "este código parece vulnerable"— a un resultado mucho más utilizable: "hemos logrado reproducir el comportamiento bajo estas condiciones".

Google precisamente presenta entornos arenosos como una de las maneras de mejorar la calidad de los resultados y limitar falsos positivos. Para verificar ciertas vulnerabilidades, el agente puede ser requerido para generar y ejecutar código. Por supuesto, esta operación no debe llevarse a cabo directamente en un entorno que contenga datos reales ni dé acceso a servicios de producción.

La documentación oficial de Mantis es particularmente clara en este punto. Google recomienda entornos aislados y restringidos, y asesora explícitamente contra el lanzamiento de este tipo de código en una máquina con acceso a sistemas de producción, datos sensibles o red interna.

Este paso ilustra una importante regla de uso profesional de la IA: cuanto más autónomo se convierte un agente, más necesita ser monitoreado su entorno de aplicación. La automatización no elimina las reglas de seguridad. Por el contrario, hace que su aplicación sea aún más importante.

6. De la detección a la propuesta correctiva

Identificar la vulnerabilidad es sólo el comienzo del trabajo. En una aplicación real, usted debe determinar por qué existe, medir sus consecuencias y preparar una corrección que no rompe otras características. Mantis está planeando una etapa dedicada a la preparación de parches.

La documentación describe un agente capaz de aplicar un cambio mínimo y luego verificar en la caja de arena que el problema previamente reproducido ya no está presente. Esta es una evolución importante de los escáneres de seguridad tradicionales. Un informe que indica "riesgo de inyección detectado en este archivo" sigue siendo útil, pero un análisis que presenta el problema, explica por qué parece real, muestra cómo se reproduce y propone una modificación aporta mucho más contexto al desarrollador.

Por lo tanto, la IA comienza a intervenir no sólo en la detección sino también en la rehabilitación. Sin embargo, esto no significa que el cambio debe aplicarse automáticamente en la producción. La corrección puede afectar una regla de negocio, cambiar el rendimiento, introducir incompatibilidad o mover el riesgo a otra parte del sistema.

7. Por qué se necesita la validación humana

La documentación de Mantis enfatiza explícitamente este tema. Los modelos d.A. son no-deterministas. Pueden alucinar una vulnerabilidad, malinterpretar el funcionamiento de una aplicación, o generar una solución errónea.

Por esta razón, Google recomienda que los nuevos usuarios comiencen con un modo interactivo. Cuando se debe realizar una acción sensible, como escribir a archivos o ejecutar un código de reproducción, el agente debe poder detenerse y solicitar la validación humana.

Como resultado, el AIA se convierte en un instrumento para ayudar a la adopción de decisiones. Puede acelerar dramáticamente algunos análisis, pero no debe convertirse en una fuente automática de confianza.

8. Lo que cambia para un SaaS o software empresarial

Para una empresa que desarrolla una aplicación, el interés principal de Mantis no es necesariamente instalar el marco inmediatamente. Lo más interesante es probablemente mirar la dirección tomada por las herramientas de desarrollo.

Tomemos un SaaS sostenido durante varios años. Se añaden nuevas características, los desarrolladores intervienen sucesivamente, las dependencias evolucionan y las partes del código gradualmente se vuelven más difíciles de entender. En este contexto, los agentes capaces de analizar la historia del proyecto, reconstruir parte de su arquitectura y buscar continuamente ciertos comportamientos sospechosos pueden proporcionar una asistencia importante.

Podrían intervenir en una revisión de códigos, cambios importantes, actualización de dependencia o control previo al despliegue. También pueden ayudar a priorizar áreas que merecen más inspección humana, documentar el camino de ejecución y reconciliar un informe con una corrección anterior.

Pero esta evolución no cambia una regla fundamental: una IA no puede compensar una arquitectura mal diseñada. Una solicitud sin separación clara de permisos, sin pruebas suficientes o sin control de sus dependencias seguirá siendo difícil de asegurar, independientemente del número de agentes utilizados.

9. ¿Puedo reemplazar una auditoría de seguridad?

No, al menos Mantis no debe ser presentado así. La seguridad de un producto de software no se limita a buscar ciertas formas de código vulnerable. El análisis integral puede requerir comprensión de arquitectura, roles y permisos, datos manipulados, reglas de negocio, infraestructura, dependencias y condiciones reales de uso.

Algunas vulnerabilidades existen sólo debido a la lógica comercial incorrecta. El código puede ser técnicamente perfectamente válido al tiempo que permite una acción que nunca debe permitirse. Una herramienta automatizada puede tener mucha más dificultad en reconocer este tipo de problema si no conoce las reglas precisas de aplicación.

Google recomienda que el análisis se enriquezca con información humana: documentación, requisitos internos y conocimientos específicos para proyectos. Como resultado, el IA puede convertirse en una herramienta adicional de alto rendimiento, pero sigue siendo una capa entre otras en una estrategia de seguridad.

10. Buenas prácticas

Incluso sin utilizar Mantis directamente, varias lecciones ya se pueden aplicar a un proyecto profesional. Un equipo humano como una IA entiende mejor un sistema cuando las responsabilidades de sus componentes están claramente definidas. La documentación sostenida también impide que las decisiones importantes desaparezcan con el tiempo.

• Mantenga una historia útil: Mantis se basa en correcciones anteriores, por lo que los cambios legibles y explicados facilitan el análisis futuro.
• Pruebe cada corrección: Las pruebas de unidad, la integración y la no regresión siguen siendo esenciales para asegurar que un parche no introduzca un nuevo problema.
• Aislar cualquier código generado: La ejecución automática nunca debe tener el mismo acceso que la aplicación de producción.
• Autorizaciones límite: red, archivos, secretos, duración, memoria y procesador debe reducirse a lo estrictamente necesario.
• Empieza pequeña: la documentación recomienda un análisis limitado para ajustar los filtros antes de escanear todo un repositorio.
• Exigir elementos verificables: una alerta no debe considerarse verdadera sólo porque está formulada con confianza.

Una historia de Git debidamente organizada tiene un valor que va más allá de la simple posibilidad de regresar. documenta intenciones, compromisos y áreas de riesgo antiguas. Asimismo, las pruebas reproducibles proporcionan una base concreta para evaluar una corrección propuesta por un humano o una IA.

11. ¿Está Mantis listo para la producción?

La respuesta requiere un matiz importante. Mantis está bien disponible en código abierto y Google proporciona instrucciones para empezar a usarlo con diferentes agentes de desarrollo. Pero su documentación no recomienda darle acceso gratuito a un sistema crítico.

Google afirma que Mantis debe ser visto como un punto de partida para adaptarse a las necesidades y el medio ambiente de cada organización. Para usos autónomos, la documentación describe medidas mejoradas: entorno aislado, permisos limitados, red controlada e infraestructura dedicada.

Para una TPE o una PYME, la enseñanza principal probablemente no es "instalar Mantis mañana en su servidor". Más bien, los instrumentos de desarrollo integrarán gradualmente capacidades analíticas y de verificación mucho más avanzadas. Antes de la adopción real, es necesario definir el alcance analizado, los datos accesibles, las acciones autorizadas, las validaciones necesarias y cómo controlar los resultados.

12. Hacia una seguridad más integrada para el desarrollo

Durante mucho tiempo, la seguridad se veía a veces como un paso separado. Una aplicación fue desarrollada y verificada antes de la entrega. Por el contrario, enfoques como los presentados por Google buscan integrar la seguridad directamente en el ciclo de desarrollo.

Google Cloud describe una arquitectura donde diferentes agentes intervienen en varias etapas del ciclo de software, desde el diseño hasta el análisis de códigos. La vulnerabilidad podría ser detectada por modificación, análisis automático y luego replicada en un entorno aislado. Se podría proponer una corrección, comprobar su comportamiento y un desarrollador revisar todo antes de validar la modificación.

El principio ya no es simplemente "ver la seguridad de la aplicación una vez terminado". Se convierte en "incorporación progresiva de los controles de seguridad en el desarrollo mismo". Este enfoque puede acortar el tiempo entre la introducción de un defecto y su detección, al tiempo que proporciona más contexto a la persona que debe tomar la decisión final.

13. Conclusión: automatizar el análisis sin automatizar la confianza

Mantis ilustra una importante evolución de la inteligencia artificial aplicada al desarrollo. Después de la generación de código, documentación o pruebas, los agentes comienzan a intervenir en tareas más complejas: analizar una arquitectura, buscar vulnerabilidades, enfrentar sus propios resultados, replicar problemas y preparar soluciones.

Para los desarrolladores, esta evolución puede ser extremadamente útil. Una IA puede navegar rápidamente una base de código importante, proporcionar contexto y llamar la atención sobre un cambio o comportamiento que merece consideración. Pero esta automatización no elimina los fundamentos. Una aplicación profesional sigue dependiendo de la calidad de su arquitectura, sus pruebas, el dominio de sus dependencias y el seguimiento realizado después de que se ponga en producción.

El futuro de la seguridad asistida por IA probablemente no está basado en un modelo capaz de hacer todo solo. Más bien, se basa en una serie de controles: analizar, confrontar, reproducir, corregir, probar y validar. Gran parte de este proceso puede ser automatizado por el IA. La confianza debe seguir siendo construida por verificación.