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

¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación? La corrección en sí rara vez es un misterio. Durante seis meses de 2026, Snyk Open Source registró 459 millones de hallazgos de vulnerabilidades en unas 300.000 organizaciones. El 94 % de esas vulnerabilidades tenía una versión corregida conocida y, aun así, solo se había resuelto alrededor del 10 %.

Esto ocurre porque lo difícil es actualizar de forma segura: la mayoría de los paquetes vulnerables se importan de forma transitiva, cerca de una cuarta parte de las correcciones requiere actualizar a una versión principal y, aunque se supone que las versiones menores y de parche son compatibles con versiones anteriores, a menudo incluyen cambios incompatibles.

VulnBump, una nueva investigación que publicamos en Snyk, pone a prueba a los agentes de IA con 307 actualizaciones reales de dependencias vulnerables. Una actualización solo cuenta como APROBADA si elimina las vulnerabilidades y el proyecto sigue instalándose, compilándose y pasando las pruebas.

Novedad: hasta donde sabemos, VulnBump es el primer benchmark para agentes de IA centrado en actualizaciones motivadas por la seguridad: cada tarea parte de vulnerabilidades reales que Snyk encontró en un proyecto real, con seis administradores de paquetes. Los benchmarks anteriores de actualizaciones solo comprueban si algo se rompe, no si desaparece la vulnerabilidad.

Entonces, ¿pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación? En general, sí, pero el modelo por sí solo no determina el resultado. Con el mismo modelo, Claude Sonnet 5.5, Evo Remediation Agent de Snyk aprobó el 90,2 % de las actualizaciones. Claude Code de Anthropic aprobó el 77,5 % cuando recibió la actualización recomendada y el análisis de Snyk (Claude Code + análisis de Snyk), y el 59,6 % sin datos de Snyk (Claude Code sin ayuda). La diferencia supera los 30 puntos porcentuales. Como referencia, la actualización con el administrador de paquetes, una línea de base sin IA que solo aplica la versión recomendada por Snyk, ya aprobó el 46,9 %.

Resultados clave de VulnBump

Mantener la compilación en verde no fue lo difícil: los tres agentes lo lograron cerca del 93 % de las veces. Lo difícil fue eliminar la vulnerabilidad. En 70 de sus 124 fallas, Claude Code, sin ayuda, afirmó haber corregido vulnerabilidades que un nuevo análisis seguía detectando.

Nuestros hallazgos coinciden con VulnBench, nuestro benchmark de junio sobre revisión de seguridad con IA, que descubrió que Claude y Snyk Code pasan por alto vulnerabilidades diferentes y concluyó que funcionan mejor en conjunto. VulnBump evalúa una tarea distinta: actualizar dependencias de código abierto vulnerables, y apunta a la misma conclusión. Con la versión recomendada y el análisis de Snyk, la tasa de aprobación de Claude Code aumentó 17,9 puntos. Evo Remediation Agent muestra cuánto más puede lograr un agente diseñado específicamente para esta tarea: 12,7 puntos por encima de Claude Code con el mismo análisis de Snyk. VulnBump también retoma los resultados de remediación que compartimos en mayo, ahora con un modelo más reciente y seis administradores de paquetes.

Cómo creamos VulnBump

Partimos de proyectos reales que reflejan el entorno de producción. Reunimos 767 proyectos candidatos de GitHub, incluidos proyectos populares de código abierto y repositorios que fijan paquetes con vulnerabilidades conocidas. Antes de cualquier cambio, cada proyecto debía instalarse, compilarse y pasar más del 85 % de sus pruebas; además, Snyk debía encontrar al menos una vulnerabilidad. De los 99 que cumplieron los requisitos, seleccionamos 43 que reflejan los datos de producción de Snyk en cuanto a ecosistema, gravedad de las vulnerabilidades, dependencias directas frente a transitivas y tamaño del salto de versión.

Comparación del conjunto de datos de VulnBump con los datos de producción de Snyk Open Source

Convertimos cada actualización recomendada en una tarea. Cada tarea le pide al agente que aplique una actualización recomendada por Snyk: un paquete actualizado a una versión que corrige sus vulnerabilidades. Cada tarea comienza con una copia nueva del proyecto y se califica por separado. Los 43 repositorios generan 307 tareas que abarcan 2.066 vulnerabilidades corregibles, con Maven, Gradle, npm, Yarn, pip y Poetry: los seis administradores de paquetes que representan cerca del 92 % de los hallazgos en producción.

Agregamos un verificador que no confiaba en el agente. Cuando el agente terminaba, copiábamos sus cambios en un contenedor limpio y los comprobábamos desde cero. Allí, un intento solo contaba como APROBADO si superaba las cuatro verificaciones:

1. Las dependencias se instalan con el comando que ejecutaría CI.

2. Un nuevo análisis de Snyk confirma que las vulnerabilidades desaparecieron.

3. El proyecto se compila.

4. Todas las pruebas que pasaban antes siguen pasando.

El flujo de VulnBump

Los entornos de prueba que evaluamos. Los tres agentes usaron Claude Sonnet 5.5, con un límite de 110 turnos por actualización y el mismo contenedor para cada lenguaje:

• Evo Remediation Agent es el motor de remediación agéntica de Snyk. Usa la inteligencia de Snyk y puede ejecutar su propio análisis, compilación y pruebas, además de reparar errores antes de terminar. Lo ejecutamos en modo de aprobación automática, por lo que aplicó todas las correcciones, incluidas las actualizaciones que Snyk considera propensas a romper la compilación.

• Claude Code con análisis de Snyk es el agente de programación de propósito general de Anthropic, al que se le proporciona la recomendación de Snyk para la actualización: el paquete que debe actualizar, la versión de destino y las vulnerabilidades que corrige. También puede ejecutar por su cuenta un análisis de Snyk Open Source para verificar su trabajo.

• Claude Code sin ayuda recibe la misma tarea, pero sin la versión de destino ni acceso a Snyk. Debe determinar por sí solo qué versión corrige las vulnerabilidades, por ejemplo, buscando en bases de datos de vulnerabilidades en la web.

• La actualización con el administrador de paquetes es la línea de base no agéntica: aplica la versión recomendada por Snyk con el administrador de paquetes del proyecto y no cambia nada más.

En el artículo de investigación: VulnBump: A Benchmark for Fixing Vulnerable Dependencies in Real Projects While Keeping the Build and Tests Green se explica cómo seleccionamos los repositorios, los prompts y herramientas exactos que recibió cada agente y los controles contra filtraciones, además de las limitaciones: probamos un solo modelo, ejecutamos cada actualización una vez y usamos Snyk Open Source como juez. Esto solo puede perjudicar a Claude Code sin ayuda, ya que los otros dos agentes usan los mismos hallazgos de Snyk. Tampoco penalizamos las nuevas vulnerabilidades introducidas por una actualización.

Resultado 1: El mismo modelo, tres resultados distintos

Evo Remediation Agent superó todas las verificaciones en el 90,2 % de las actualizaciones (y corrigió el 95,9 % de las 2.066 instancias de vulnerabilidad). Eso representa 12,7 puntos más que Claude Code + análisis de Snyk, aproximadamente una corrección exitosa adicional cada ocho actualizaciones, y 30,6 puntos más que Claude Code sin ayuda.

Y la clasificación no depende solo de unos pocos repositorios grandes: al promediar las tasas de aprobación por repositorio, Evo Remediation Agent obtuvo un 93,1 %, Claude Code + análisis de Snyk un 80,1 %, Claude Code sin ayuda un 68,0 % y la actualización con el administrador de paquetes un 51,3 %.

Resultado 2: Los agentes deben saber qué versión es realmente segura

Con el mismo modelo, proporcionarle a Claude Code el análisis de Snyk y la actualización recomendada aumentó su tasa de aprobación 17,9 puntos, del 59,6 % al 77,5 %.

La diferencia más clara está en la versión que elige. Sin ayuda, Claude Code se decidió por una versión que Snyk siguió marcando como vulnerable en 64 ocasiones. Con el análisis de Snyk, esa cifra bajó a 13. Las bases de datos de vulnerabilidades no siempre coinciden en qué versión corrige una vulnerabilidad, así que una versión que parece segura en una fuente puede seguir apareciendo como vulnerable en otra.

La orientación de Snyk es más importante para las vulnerabilidades transitivas, en paquetes que el proyecto no declara directamente. Si contamos solo las actualizaciones que superaron todas las verificaciones, más que duplicó la proporción de vulnerabilidades que corrigió Claude Code: del 28 % al 59 %.

Resultado 3: Las recomendaciones de Snyk por sí solas resuelven cerca de la mitad; luego los agentes se diferencian en el resto

La actualización con el administrador de paquetes divide las 307 actualizaciones en dos grupos: en las 144 que aprueba, basta con la versión recomendada por Snyk y un agente solo puede conservar o echar a perder una corrección sencilla. Las otras 163 requieren algo más que actualizar la versión, como adaptar el código a cambios incompatibles o resolver conflictos entre dependencias.

Agentes con las 144 actualizaciones que resuelve la recomendación de Snyk y con las otras 163

Con la orientación de Snyk, los agentes rara vez estropean lo que resuelve la actualización, mientras que Claude Code sin ayuda retrocedió en 20 de las 144 actualizaciones; en 15 de ellas, eligió una versión que Snyk seguía marcando como vulnerable. La diferencia real se ve en la mitad difícil: de las otras 163 actualizaciones, Evo Remediation Agent aprobó el 82,2 %, Claude Code + análisis de Snyk el 61,3 % y Claude Code por sí solo el 36,2 %.

Resultado 4: Una compilación en verde puede ocultar una vulnerabilidad sin corregir

La forma más fácil de mantener una compilación en verde es dejar la vulnerabilidad sin resolver, y eso fue lo que vimos principalmente en las fallas de Claude Code. El nuevo análisis fue la primera verificación en fallar en 107 de las 124 fallas de Claude Code sin ayuda, en 48 de las 69 de Claude Code + análisis de Snyk y en 9 de las 30 de Evo Remediation Agent.

Primera verificación que falló en cada intento no aprobado

Las fallas de Evo Remediation Agent son visibles (y eso no es malo). En 21 de sus 30 fallas, se rompieron la compilación o las pruebas, principalmente en actualizaciones a versiones principales que otros agentes solían evitar. Una falla evidente es mucho más segura que una silenciosa: cuando una actualización sale mal, la compilación y las pruebas del propio proyecto lo muestran, para que un desarrollador pueda verlo y, finalmente, actuar.

Resultado 5: Saber cuál es la versión de destino no basta

El análisis de Snyk ayuda mucho a Claude Code, pero completar bien la actualización requiere algo más: con hallazgos y versiones de destino idénticos, Evo Remediation Agent aprobó 39 actualizaciones más que Claude Code con análisis de Snyk; 23 de ellas eran saltos a versiones principales.

Evo Remediation Agent combina la inteligencia de Snyk con un ciclo en el que compila, prueba y repara el proyecto antes de terminar. Aunque nuestra configuración no permite aislar qué componente marca la diferencia, sí muestra cuánto puede influir en el resultado el sistema que rodea al modelo, en consonancia con DepBench, donde cambiar únicamente el entorno de ejecución modificó los resultados hasta en 16,3 puntos.

Resultado 6: Los grandes saltos de versión y las dependencias transitivas siguen siendo las tareas más difíciles

Todos los agentes siguen teniendo dificultades con las migraciones importantes de frameworks: las 23 actualizaciones —en su mayoría migraciones de Spring, Spring Boot y Dropwizard— superaron a los tres agentes.

En las actualizaciones a versiones principales frente a las que no lo eran, las tasas de aprobación cayeron del 96 % al 81 % para Evo Remediation Agent, del 88 % al 61 % para Claude Code + análisis de Snyk y del 70 % al 42 % para Claude Code sin ayuda. Las actualizaciones principales también exigen cambios en el código: en cerca de la mitad de las actualizaciones principales aprobadas por Evo Remediation Agent se modificó el código fuente de la aplicación, frente al 5 % de las actualizaciones no principales aprobadas.

Actualizaciones que superaron todas las verificaciones, según el tamaño del salto de versión

Las vulnerabilidades transitivas, en las que el paquete vulnerable no está declarado en el manifiesto, representan el 70 % de las instancias corregibles y son más difíciles para todos los entornos de ejecución evaluados. Si contamos solo las correcciones de intentos que superaron todas las verificaciones, Evo Remediation Agent corrigió el 73 % de las instancias transitivas, Claude Code + análisis de Snyk el 59 % y Claude Code sin ayuda el 28 %, frente al 91 %, 71 % y 62 %, respectivamente, de las directas.

Tasa de aprobación por tipo de dependencia (directa frente a transitiva)

¿Cómo se relaciona VulnBump con VulnBench?

VulnBench evalúa cómo los agentes de programación con IA encuentran vulnerabilidades en el código que escribes: con qué consistencia detectan los mismos problemas en ejecuciones repetidas y qué tanto coinciden sus hallazgos con una línea de base SAST determinista. VulnBump evalúa si pueden corregir vulnerabilidades en el código del que dependes: actualizando dependencias de código abierto vulnerables sin romper la compilación ni las pruebas.

Al leer ambos juntos, la conclusión es la misma: los modelos aportan capacidad de razonamiento que las herramientas deterministas simplemente no tienen. Por sí solos, reportan hallazgos distintos en cada ejecución y a menudo no llegan a corregirlos. En toda la plataforma, resumimos esta lección compartida de forma más sencilla: el generador no puede ser el validador.

¿Qué significa esto para los equipos que delegan tareas de seguridad en agentes?

• Evalúa una corrección con pruebas que el agente no haya generado: el informe del agente sobre su propia corrección es una afirmación; un nuevo análisis, una compilación y una ejecución de pruebas son pruebas. Si un agente está corrigiendo tu lista de pendientes, exige las mismas comprobaciones.

• Evalúa en conjunto la vulnerabilidad y la compilación: cualquiera de las dos por sí sola puede ocultar una falla. Las comprobaciones que solo detectan problemas de compilación no identifican las correcciones que nunca se hicieron, mientras que las que solo detectan vulnerabilidades no identifican una corrección que rompió el proyecto.

• Dale al agente los datos de seguridad: el análisis de Snyk y la actualización recomendada le dieron a un agente de propósito general una ventaja de 17.9 puntos con el mismo modelo.

Evo Remediation Agent es el motor de remediación agéntica de Snyk, disponible a través de Snyk CLI y como servicio en la nube. Es uno de los agentes de Evo Agentic AppSec, que se lanza hoy.

Pon a prueba tu agente con VulnBump

El harness de VulnBump y los 43 casos de evaluación son de código abierto en github.com/snyk-labs/snyk-vulnbump.

La metodología completa, el análisis de fallas y las limitaciones están en el artículo de investigación. Si estás creando un agente de remediación, ponlo a prueba con VulnBump y cuéntanos qué descubres.

VulnBump fue creado por Gabija Pasiunaite, Ryan McMorrow, Brian Clark, Liran Tal y Luke Tu.