Skip to main content

Agentes de remediación, sin misterios: por qué solucionar es mejor que encontrar

Escrito por
Headshot of Snyk Team

Snyk Team

19 de agosto de 2026

0 minutos de lectura

Seis nuevos problemas de seguridad por cada uno problema corregido. Esa es la proporción que ha descubierto la investigación de Snyk, y por eso la comunidad de ingenieros de seguridad de IA dedicó una hora de transmisión en directo a corregir en lugar de encontrar.

Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

Agentes de corrección: desmitificados combinó una charla informal con una demostración en directo. Gérald Crescione, responsable de la comunidad global de ingenieros de seguridad de IA, fue el anfitrión junto con Ryan McMorrow, quien lidera los productos de corrección en Snyk, y Brendan Hann, responsable sénior de marketing de producto para la experiencia del desarrollador y la solución Agentic AppSec de Snyk.

Remediation Agent, actualmente en vista previa pública, es la respuesta de Snyk al problema del volumen de incidencias que estamos observando. Mientras el equipo continúa desarrollando e iterando públicamente, Snyk ofrece Remediation Agent a todos los clientes actuales de Snyk sin coste adicional, a cambio de comentarios prácticos de la comunidad. Estos comentarios se pueden compartir en el subreddit de la comunidad.

Por qué la tasa de corrección se mantuvo estable

Los agentes de programación que los desarrolladores utilizan ahora en todas partes optimizan el código funcional, no el código funcional seguro, por lo que el volumen de incidencias aumenta mientras la tasa de corrección se mantiene estable. Las herramientas de AppSec respondieron con recomendaciones deterministas: estás en la versión 1.0, la vulnerabilidad está corregida en la 1.1, así que actualiza. Bien hasta cierto punto, salvo que alguien todavía tiene que demostrar que la actualización no rompió nada, y ninguna herramienta hacía eso en nombre del desarrollador. Cuando el salto abarcaba tres o cuatro versiones principales, la mayoría de los equipos nunca encontraban la confianza necesaria para fusionar los cambios.

Hann situó ese cuello de botella dentro de un cambio más amplio. La IA ha creado tres presiones distintas pero relacionadas: los ataques ahora están automatizados con IA; los agentes escriben software más rápido que nunca e introducen vulnerabilidades al mismo ritmo; y la IA está llegando a producción, a menudo sin gobernanza. La corrección siempre fue un cuello de botella, argumentó, pero ahora importa más porque las herramientas de los atacantes también cambiaron de forma. Los modelos de vanguardia rompen los entornos aislados y encadenan hallazgos de baja gravedad que antes podían ignorarse para crear nuevos ataques de día cero. La acumulación de riesgos aceptados se ha convertido en una superficie de ataque por derecho propio.

Agentic AppSec aborda esa combinación: controles preventivos, detección de nivel vanguardista y corrección autónoma; en palabras de Hann, proporciona a los equipos un equipo de agentes que puede ejecutar realmente su programa de AppSec por ellos.

Por qué lanzar un LLM contra la acumulación de incidencias no funciona

Los investigadores de Snyk hicieron primero lo obvio: dirigieron un LLM a la acumulación de incidencias de seguridad para ver qué ocurría.

El modelo demostró ser extremadamente entusiasta y solo acertó ocasionalmente. Los desarrolladores todavía tenían que revisar cada cambio y rechazar la mayoría, lo que costaba casi tanto tiempo como corregir las incidencias manualmente. Un modelo más grande habría producido más de lo mismo.

El cambio llegó cuando el equipo planteó una pregunta diferente: ¿qué pasaría si el LLM recibiera todo lo que Snyk sabe? Diez años de buenas prácticas de seguridad de aplicaciones, conocimientos específicos sobre actualizaciones de ecosistemas y experiencia adquirida a base de esfuerzo sobre qué correcciones se fusionan y cuáles no.

Así nació Remediation Agent, descrito por McMorrow como un arnés o capa de orquestación situada entre el modelo elegido por el desarrollador y una capa de inteligencia invocable que cubre cada incidencia y CVE que Snyk rastrea. Bajo demanda, el agente puede obtener:

  • Evaluaciones de capacidad de ruptura para actualizaciones de código abierto, con una puntuación de la probabilidad de que una actualización rompa tu compilación, extraídas de una base de datos con cada versión de paquete y cada cambio incompatible que contiene

  • Estado de los paquetes y puntuaciones de alcanzabilidad, incluido si el código vulnerable es explotable en producción

  • Generación de correcciones SAST mediante la funcionalidad Agent Fix de Snyk

  • Manuales de ecosistemas escritos por los propios ingenieros de seguridad de Snyk, que explican cómo un profesional sénior actualizaría una dependencia transitiva o eliminaría una clase determinada de hallazgos SAST

La analogía de McMorrow fue que al LLM se le proporciona un examen con libro abierto, y Snyk aporta el libro. Después, Snyk califica los deberes del agente, vuelve a ejecutar los análisis para confirmar que la incidencia ha desaparecido realmente y ejecuta las pruebas unitarias del proyecto para garantizar que los cambios no rompieron la compilación.

Los resultados internos que compartió fueron una mejora del 94 % en las correcciones SCA aptas para fusionarse y una mejora del 13 % en las correcciones SAST aptas para fusionarse; la mayoría de las correcciones SAST generadas internamente ahora se fusionan tal cual, con un coste de tokens significativamente menor que el del enfoque ingenuo.

Hann añadió los tres patrones con los que los socios de diseño de Snyk han tenido más éxito:

  1. Campañas de reducción de la acumulación de incidencias, eliminando los hallazgos de nivel bajo e informativo que los atacantes ahora encadenan

  2. Despliegues en toda la organización que proporcionan a cada desarrollador un agente de corrección

  3. Uso del agente de corrección en entornos de desarrollo agéntico (ADE) para evitar que nuevas incidencias entren en la base de código

La demostración: IDE y CLI

McMorrow ejecutó el agente en directo contra OWASP Juice Shop y mostró ambos puntos de entrada.

1. La ruta del IDE

La ruta del IDE necesita dos elementos: una /snyk-fix habilidad y el servidor MCP de Snyk Studio, ambos instalables con un solo comando curl desde el repositorio de recetas de Snyk. Esto proporciona el ciclo completo dentro de Cursor, Windsurf, Antigravity o VS Code con un complemento de Claude, desde los análisis SAST y SCA hasta la consulta de inteligencia, los cambios de código, el nuevo análisis, la ejecución de pruebas, el informe y la solicitud de incorporación de cambios. En el escenario, actualizó una dependencia multer vulnerable entre versiones principales, confirmó que ningún cambio incompatible de la API afectaba al uso del almacenamiento en disco de la aplicación y actualizó el archivo de bloqueo.

2. La ruta de la CLI

En la CLI, snyk fix --agentic --experimental --sca es más participativa. Enumera cada paquete que considera que puede actualizar, junto con la versión actual, la versión de destino que Snyk recomienda porque elimina la mayor cantidad de incidencias críticas y graves, así como una puntuación de capacidad de ruptura. Los desarrolladores pueden:

  • Corregir todo

  • Corregir solo los elementos con baja capacidad de ruptura

  • Seleccionar hallazgos específicos

  • Hablar con el agente

McMorrow demostró la última opción preguntando por qué un salto de Glob versión principal tenía un riesgo alto, y el agente devolvió el razonamiento: un cambio a una API basada en promesas, el estilo de callbacks obsoleto, los separadores de ruta convertidos en caracteres que solo sirven para escapes y la clase Glob que ya no era un emisor de eventos. También enumeró las vulnerabilidades transitivas que la actualización resolvería. La versión más reciente utiliza después esa misma inteligencia sobre la capacidad de ruptura para realizar los cambios de código compensatorios, convirtiendo una actualización de alto riesgo en una de bajo riesgo.

Cuando le preguntaron de dónde procedía la justificación, McMorrow explicó que el razonamiento sobre la capacidad de ruptura se basa en un análisis de las notas de versión y los cambios incompatibles de todo el ecosistema de código abierto. Los socios de diseño han informado de pocos falsos positivos. Se trata principalmente de una preocupación del lado de SAST, y el agente utiliza los motores existentes de Snyk Code para filtrarlos.

Una persona en el proceso y después una persona supervisando el proceso

Todas las rutas de la demostración terminaban en una solicitud de incorporación de cambios. «No vamos por ahí haciendo cambios de código disparatados», como dijo Hann, y el desarrollador conserva la aprobación final hasta que un agente se ha ganado suficiente confianza como para que cualquiera fusione su trabajo sin pensarlo.

Los propios equipos de Snyk ejecutan hoy el agente desde la CLI, y hay una variante autónoma en desarrollo activo: Snyk inicia un entorno aislado, instala el agente, incorpora el código de la aplicación y devuelve una solicitud de incorporación de cambios terminada. Antes, la canalización de CI de Snyk se detenía ante vulnerabilidades nuevas y devolvía el problema al desarrollador; ahora genera las correcciones en su lugar, y fusionas el trabajo del agente junto con tu propio commit. Los ingenieros, informó McMorrow, agradecen no tener que volver a intervenir.

Hann señaló «acumulación cero» como un objetivo realista, así como el bloqueo de paquetes maliciosos y del slopsquatting a nivel del equipo del desarrollador y de la organización. McMorrow sostuvo que el objetivo a largo plazo es el control, la gobernanza y la confianza: pasar de una persona en el proceso a una persona supervisando el proceso. La diferencia es quién decide: estar en el proceso es programar en pareja con un agente, mientras que supervisar el proceso es contar con un agente que decide por sí mismo y sabe cuándo llamarte. La aportación de Crescione: ese es el perfil profesional emergente, ingenieros de seguridad de IA que orquestan un grupo de agentes en su nombre.

Manos a la obra

Para empezar necesitas una cuenta de Snyk y la CLI o un ADE compatible, además de tu propia clave de API del modelo, ya que aportar tu propio LLM es la opción predeterminada para la vista previa abierta. Los mantenedores de código abierto pueden obtener toda la plataforma gratis mediante el Secure Developer Program, que incluye una licencia empresarial completa.

¿Has encontrado una corrección que no da en el blanco? Cuéntanoslo en r/AISecEng. Tus comentarios ayudarán a definir el próximo rumbo de Remediation Agent mientras Snyk continúa desarrollando e iterando públicamente.

BOOK A LIVE DEMO

Secure AI adoption at scale

Evo helps organizations safely adopt and scale AI by providing visibility, governance, and security across AI-driven development and AI applications.