Legit Security: su agente de IA ya corrige dependencias

Legit Security ha ampliado su función Agentic Remediation para que ahora también se ocupe de las vulnerabilidades en dependencias de código abierto, y no solo en el código que escribe la propia empresa. El objetivo es llevar a los equipos de desarrollo desde la detección de una vulnerabilidad hasta una corrección verificada sin que nadie tenga que clasificar el problema a mano.

Hasta ahora, el agente trabajaba con los hallazgos del análisis estático en código propio, es decir, el código escrito por los ingenieros de la empresa. La nueva versión dirige ese mismo agente hacia los paquetes que se incorporan desde fuera, que la compañía describe como la otra gran fuente de vulnerabilidades en el software moderno.

Un problema de volumen

Legit Security presenta la actualización como respuesta a una brecha cada vez mayor en la seguridad de aplicaciones (AppSec). El código generado por IA está acelerando la entrega de software, y la mayoría de las bases de código actuales están formadas en gran parte por dependencias de código abierto. Cada paquete nuevo puede traer consigo vulnerabilidades conocidas.

El flujo de trabajo clásico de AppSec, en el que equipos humanos van resolviendo uno a uno una lista de hallazgos pendientes, no da abasto con ese volumen. Y la cosa se complica cuando el código defectuoso no está en el repositorio de la empresa, sino enterrado varias capas más abajo dentro de un paquete de terceros.

"El verdadero reto ya no es encontrar vulnerabilidades, sino pasar de la detección a la corrección con la rapidez suficiente", afirmó la empresa. Añadió que el código generado por IA ha multiplicado la cantidad de software que se publica cada día, mientras que los atacantes recurren cada vez más a la IA para encontrar y explotar fallos más rápido de lo que los defensores pueden reaccionar. Esa preocupación encaja con una tendencia más amplia de IA que acelera la explotación que los equipos de seguridad llevan tiempo siguiendo.

Cinco pasos hasta la pull request

Cuando el agente recibe una dependencia vulnerable, sigue una secuencia fija:

• Identifica el paquete afectado, su versión actual y si se trata de una dependencia directa o de una transitiva incorporada por otro paquete.
• Elige la actualización más segura, que es el menor salto de versión que resuelve el problema. Siempre que sea posible, se mantiene dentro de la versión mayor actual para evitar cambios incompatibles.
• Aplica la corrección actualizando la configuración de dependencias y regenerando el lockfile. Esto incluye también otras apariciones de la versión vulnerable en otros puntos del árbol de dependencias.
• Verifica el resultado analizando la dependencia antes y después del cambio. La comprobación confirma que el fallo ha desaparecido y que no ha surgido ningún problema nuevo.
• Abre una pull request lista para revisión, con la corrección y los detalles de la vulnerabilidad adjuntos.

Como cada corrección se vuelve a analizar antes de crear la PR, los desarrolladores reciben un cambio ya comprobado, en lugar de una versión sugerida que todavía tienen que probar por su cuenta.

Cuando hace falta saltar de versión mayor

Algunas correcciones solo existen en una versión mayor más reciente, donde los cambios incompatibles en la API se convierten en un riesgo real. En esos casos, el agente añade un paso de análisis asistido por IA. Examina cómo usa el paquete ese repositorio concreto y propone los cambios en el código fuente necesarios para adaptarse. Estas propuestas se validan con los datos reales del repositorio y del paquete.

Legit Security traza una línea clara entre las dos partes de una corrección de este tipo. La actualización de la dependencia en sí se verifica volviendo a analizarla, como cualquier otra corrección. En cambio, la adaptación del código para el salto de versión mayor la evalúa la IA y no se verifica de forma independiente. Según la empresa, la PR indica esta distinción de forma explícita, para que los desarrolladores vean qué se ha confirmado y qué conviene revisar con más detalle antes de fusionar.

Nuestro análisis

Este lanzamiento encaja con una pauta que hemos visto en todo el sector en las últimas semanas: los fabricantes están llevando la IA de detectar problemas a corregirlos de verdad. Gemini 4 Argon de Google, que encuentra y parchea fallos, y Sophos, que usa la IA para priorizar correcciones, apuntan en la misma dirección.

Para los lectores, el detalle más interesante es que la propia Legit Security admite que las adaptaciones de código escritas por la IA no se verifican de forma independiente. Esto sugiere que la revisión humana no va a desaparecer, sobre todo en las actualizaciones de versión mayor. Además, el riesgo de las dependencias va más allá de las versiones desactualizadas, como demuestran incidentes como la brecha en el Artifactory de OpenInfra Europe. Habrá que ver si los equipos confían lo suficiente en estas PR automatizadas como para fusionarlas rápidamente, y con qué frecuencia los cambios evaluados por la IA aguantan en producción.