Skip to main content

Remediation Agent, sin misterios: por qué corregir es mejor que detectar

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 que se remedia. Esa es la proporción que encontró la investigación de Snyk, y por eso la comunidad AI Security Engineers dedicó una hora de su transmisión en vivo a corregir en lugar de detectar.

Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

Remediation Agents Demystified combinó una charla informal con una demostración en vivo. Gérald Crescione, director de la comunidad global AI Security Engineers, fue el anfitrión, junto con Ryan McMorrow, líder de productos de remediación en Snyk, y Brendan Hann, gerente sénior de marketing de producto para la experiencia de desarrollo y la solución Agentic AppSec de Snyk.

Remediation Agent, ahora en versión preliminar pública, es la respuesta de Snyk al volumen de problemas que estamos viendo. Mientras el equipo sigue desarrollando e iterando en público, Snyk ofrece Remediation Agent a todos sus clientes actuales sin costo adicional, a cambio de comentarios prácticos de la comunidad. Puedes compartirlos en el subreddit de la comunidad.

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

Los agentes de codificación que los desarrolladores usan ahora en todas partes optimizan el código funcional, no el código funcional seguro. Por eso, el volumen de problemas aumenta mientras la tasa de corrección se mantiene estable. Las herramientas de AppSec respondieron con recomendaciones deterministas: usas la versión 1.0 y la vulnerabilidad está corregida en la 1.1, así que actualiza. Eso está bien hasta cierto punto, pero alguien todavía tiene que demostrar que la actualización no rompió nada, y ninguna herramienta lo hacía en nombre del desarrollador. Cuando el salto abarca tres o cuatro versiones principales, la mayoría de los equipos nunca se sentía con la confianza suficiente para fusionar los cambios.

Hann situó ese cuello de botella dentro de un cambio más amplio. La IA ha generado tres presiones distintas, pero relacionadas: los ataques ahora se automatizan 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. Según explicó, la remediación siempre ha sido un cuello de botella, pero ahora importa más porque las herramientas de los atacantes también cambiaron. Los modelos de vanguardia escapan de los entornos aislados y encadenan hallazgos de baja severidad, antes ignorables, para crear vulnerabilidades de día cero novedosas. La acumulación de riesgos aceptados se ha convertido en una superficie de ataque en sí misma.

Agentic AppSec aborda esa combinación: controles preventivos, detección de nivel vanguardista y remediación autónoma. En palabras de Hann, permite equipar a los equipos con un equipo de agentes que realmente puede ejecutar su programa de AppSec.

Por qué no sirve lanzar un LLM al backlog

Los investigadores de Snyk hicieron lo primero que parecía obvio: apuntar un LLM al backlog de seguridad y ver qué pasaba.

El modelo demostró un entusiasmo desbordante y acertó solo de vez en cuando. Los desarrolladores aún tenían que revisar cada cambio y rechazar la mayoría, lo que tomaba casi tanto tiempo como corregir los problemas a mano. Un modelo más grande habría producido más de lo mismo.

El cambio llegó cuando el equipo hizo otra pregunta: ¿qué pasaría si el LLM tuviera acceso a todo lo que sabe Snyk? Diez años de prácticas recomendadas de seguridad de aplicaciones, conocimientos sobre actualizaciones específicas de cada ecosistema y experiencia ganada con esfuerzo sobre qué correcciones se fusionan y cuáles no.

Así nació Remediation Agent, que McMorrow describió como un arnés o una capa de orquestación entre el modelo que elige el desarrollador y una capa de inteligencia invocable que abarca todos los problemas y CVE que Snyk monitorea. Cuando se le solicita, el agente puede acceder a:

  • Evaluaciones de breakability para actualizaciones de código abierto, con una puntuación que indica la probabilidad de que una actualización interrumpa tu compilación, basada en una base de datos con todas las versiones de paquetes y cada cambio incompatible

  • Estado del paquete y puntuaciones de reachability, incluido si el código vulnerable se puede explotar en producción

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

  • Guías para cada ecosistema redactadas por los propios ingenieros de seguridad de Snyk, que explican cómo un profesional sénior actualizaría una dependencia transitiva o resolvería una clase determinada de hallazgos SAST

McMorrow comparó la situación con un examen a libro abierto: el LLM recibe un examen y Snyk aporta el libro. Luego, Snyk califica la tarea del agente y vuelve a ejecutar análisis para confirmar que el problema realmente desapareció. También ejecuta las pruebas unitarias del proyecto para asegurar que los cambios no hayan interrumpido la compilación.

Los resultados internos que compartió mostraron una mejora del 94 % en las correcciones SCA listas para fusionar y del 13 % en las correcciones SAST listas para fusionar. Ahora, la mayoría de las correcciones SAST generadas internamente se fusionan tal cual, con un costo en tokens considerablemente menor que el del enfoque ingenuo.

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

  1. Campañas para reducir el backlog y resolver los hallazgos de gravedad baja e informativos que los atacantes ahora encadenan

  2. Implementaciones en toda la organización que ponen un agente de remediación al lado de cada desarrollador

  3. Uso del agente de remediación en entornos de desarrollo agéntico (ADE) para evitar que nuevos problemas lleguen a la base de código

La demostración: IDE y CLI

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

1. El flujo en el IDE

El flujo en el IDE requiere dos componentes: una habilidad /snyk-fix y el servidor MCP de Snyk Studio. Ambos se pueden instalar con un solo comando curl desde el repositorio de recetas de Snyk. Así tienes 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 el pull request. En la demostración, el agente actualizó una dependencia vulnerable de multer a través de una versión principal, confirmó que ningún cambio incompatible en la API afectaba el uso de almacenamiento en disco de la aplicación y actualizó el archivo de bloqueo.

2. El flujo en la CLI

En la CLI, snyk fix --agentic --experimental --sca permite una mayor participación. Muestra cada paquete que cree poder actualizar, junto con la versión actual, la versión de destino recomendada por Snyk porque resuelve la mayor cantidad de problemas críticos y altos, y una puntuación de breakability. Los desarrolladores pueden:

  • Corregir todo

  • Corregir solo los elementos con baja breakability

  • Seleccionar hallazgos específicos

  • Conversar con el agente

McMorrow demostró la última opción al preguntar por qué un salto de versión principal de Glob tenía un riesgo alto. El agente explicó el motivo: el cambio a una API basada en promesas, el estilo de devolución de llamada obsoleto, los separadores de ruta que pasan a ser caracteres de escape y la clase Glob, que deja de ser un emisor de eventos. También enumeró las vulnerabilidades transitivas que resolvería la actualización. Luego, la versión más reciente usa esa misma inteligencia de breakability para hacer los cambios compensatorios en el código y convertir una actualización de alto riesgo en una de bajo riesgo.

Al preguntarle de dónde provenía la justificación, McMorrow explicó que el razonamiento sobre breakability se basa en analizar las notas de lanzamiento y los cambios incompatibles en todo el ecosistema de código abierto. Los socios de diseño han reportado pocos falsos positivos. Estos se concentran sobre todo en el lado de SAST, y el agente usa los motores existentes de Snyk Code para filtrarlos.

Primero, una persona en el proceso; después, una persona supervisándolo

En la demostración, todos los flujos terminaban en un pull request. «No estamos haciendo cambios de código disparatados», dijo Hann, y el desarrollador conserva la aprobación final hasta que el agente se haya ganado la confianza suficiente para que alguien fusione sus cambios sin revisarlos.

Hoy, los propios equipos de Snyk ejecutan 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 un PR terminado. Antes, el pipeline de CI de Snyk se detenía ante vulnerabilidades nuevas y devolvía el problema al desarrollador; ahora genera las correcciones, y tú fusionas el trabajo del agente junto con tu propio commit. Según McMorrow, a los ingenieros les encanta no tener que volver a ocuparse de eso.

Hann señaló que «cero backlog» es un objetivo realista, y que se pueden bloquear paquetes maliciosos y ataques de slopsquatting en los equipos de los desarrolladores y a nivel de la organización. McMorrow sostuvo que el objetivo a largo plazo es el control, la gobernanza y la confianza: pasar de tener a una persona en el proceso a tenerla supervisándolo. La diferencia está en quién toma las decisiones: en el proceso, la persona programa en pareja con un agente; supervisándolo, el agente decide por sí mismo y sabe cuándo llamarla. Crescione agregó que ese es el perfil laboral emergente: AI Security Engineers 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 de modelo, ya que usar tu propio LLM es la opción predeterminada en la versión preliminar abierta. Los responsables de proyectos de código abierto pueden acceder gratis a toda la plataforma a través del Secure Developer Program, que incluye una licencia empresarial completa.

¿Encontraste una corrección que no da en el blanco? Cuéntanos en r/AISecEng. Tus comentarios ayudarán a definir los próximos pasos de Remediation Agent mientras Snyk sigue desarrollando e iterando en público.

RESERVA UNA DEMOSTRACIÓN EN VIVO

Adopta la IA de forma segura y a escala

Evo ayuda a las organizaciones a adoptar y ampliar el uso de la IA de forma segura, con visibilidad, gobernanza y protección en el desarrollo impulsado por IA y las aplicaciones de IA.

Leer más

blog feature snyk container custom base recommendations
Blog

Presentamos Evo Agentic AppSec: seguridad que sigue el ritmo del desarrollo con IA

El desarrollo impulsado por IA avanza más rápido que los flujos de trabajo de seguridad tradicionales. Agentic AppSec de Snyk usa agentes de seguridad para encontrar, corregir y verificar vulnerabilidades de forma continua, mientras las personas establecen el nivel.

blog feature ai violet
Blog

VulnBump: ¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación?

VulnBump prueba agentes de IA con 307 actualizaciones reales de dependencias. Una corrección cuenta solo si elimina la vulnerabilidad y la compilación y las pruebas siguen pasando.

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.