El 'Left' del Shift-Left se ha movido: agentes de código, VibeGuard y el nuevo perímetro de AppSec

El artículo de Chris Hughes parte de una tesis que ya ha desarrollado en piezas anteriores de su newsletter: la IA ha industrializado el descubrimiento de vulnerabilidades a un ritmo que el ecosistema institucional de divulgación, triaje y parcheo nunca fue diseñado para absorber. Pero el foco de este texto no es esa 'Vulnpocalypse', sino un segundo desplazamiento que, según el autor, recibe mucha menos atención: el lugar donde se escribe el código y cómo se mueve, ahora que ese código lo produce cada vez más un agente que corre directamente en el puesto de trabajo del desarrollador.

En la parte del descubrimiento, el autor cita varias fuentes para mostrar la magnitud del fenómeno. El investigador Jerry Gamblin señaló que se publicaron 35.364 CVE entre el 1 de enero y el 30 de junio, un 49,5% más que en el mismo periodo de 2025, es decir, una nueva entrada cada 7,4 minutos, con una proyección anual de entre 71.314 y 72.008 CVE frente a los 48.185 de todo 2025. FIRST, por su parte, ajustó su previsión a mitad de año hasta unos 66.000 CVE, partiendo de una base de 59.427 en febrero, y sostuvo que el problema real ya no es encontrar vulnerabilidades, sino tener capacidad para verificarlas, coordinarlas y priorizarlas a escala.

El texto añade los datos de los propios laboratorios de IA: el proyecto Glasswing de Anthropic dice haber identificado más de diez mil vulnerabilidades de severidad alta o crítica entre sus socios, y específicamente 6.202 hallazgos de alta o crítica severidad en proyectos de código abierto, de los cuales el 90,6% de los 1.752 ya evaluados resultaron ser verdaderos positivos; algunos socios reportaron un aumento de más de 10 veces en su ritmo de detección de fallos, hasta el punto de pedir a Anthropic que ralentizara las divulgaciones. El esfuerzo 'Patch the Planet' de OpenAI, centrado en 55 proyectos críticos de código abierto, había encontrado 1.535 problemas en el momento de escribirse el artículo, de los cuales más de 1.000 seguían sin parche. El investigador Casey Ellis lo resume con una frase que el autor reproduce: la IA ha colapsado el coste de encontrar y reportar vulnerabilidades a la vez, con señal y ruido multiplicados por diez y una brecha entre ambos cada vez mayor, de modo que 'la Vulnpocalypse ya estaba aquí, simplemente no estaba distribuida uniformemente'.

Esa presión ya está rompiendo la capacidad de absorción del ecosistema: cURL llegó a pausar temporalmente su programa de recompensas por fallos tras caer su tasa de confirmación de un 15% a un 5% en 2025 (después mejorada gracias a reportes de mayor calidad generados con IA), y el Internet Bug Bounty de HackerOne detuvo nuevas presentaciones en marzo. NIST, por su parte, registró un crecimiento del 263% en los envíos de CVE entre 2020 y 2025 y trasladó la mayoría a un nivel de 'no programado para enriquecimiento inmediato'. Aun así, Gamblin matiza que, pese a que la curva de volumen se ha disparado, la explotación real sigue plana, entre el 1% y el 2%: solo 85 de los CVE publicados en el primer semestre de 2026 (un 0,24%) habían entrado en el catálogo KEV de CISA, lo que lleva a FIRST a describir la situación como 'lluvia frente a inundación': hay que dejar de mirar el volumen bruto y centrarse en qué es lo que realmente hay que remediar, aunque el autor reconoce que en la práctica es difícil discriminar eso cuando las vulnerabilidades llegan a velocidad de máquina.

La segunda parte del artículo aborda el lado de la remediación, que sigue funcionando a velocidad humana. Tanto Glasswing como Patch the Planet muestran que dos tercios o más de las vulnerabilidades detectadas, incluso ya verificadas, siguen sin parche. Anthropic lo formula así: 'la relativa facilidad de encontrar vulnerabilidades frente a la dificultad de solucionarlas supone un reto mayor para la ciberseguridad', una frase que el autor interpreta como el reconocimiento, por parte de un laboratorio de frontera, del mismo cuello de botella que los profesionales llevan años sufriendo, ahora agravado por la IA. Cita también datos de Cyentia según los cuales una organización típica solo tiene capacidad para remediar una de cada diez vulnerabilidades al mes, y esto antes de que el descubrimiento se industrializara; y el informe DBIR 2026 de Verizon, que sitúa la mediana de tiempo hasta el parcheo completo en 43 días, con solo un 26% de las vulnerabilidades listadas en KEV totalmente remediadas, mientras la explotación se convirtió en el vector inicial más frecuente, con un 31% de las brechas.

Según el autor, generar un parche se ha abaratado gracias a la IA igual que ocurrió con la detección, pero el problema real es saber si el parche es correcto, si rompe algo tres servicios más allá, si el hallazgo era siquiera explotable en la práctica, y quién es responsable cuando un arreglo escrito por un agente para un código también escrito por un agente llega a producción. Cita a Niels Provos, quien sostiene que la remediación es el cuello de botella que la IA aún no ha resuelto, y coincide con matices: se trata, dice, de un problema de diseño del programa de AppSec más que de capacidad del modelo.

El núcleo del artículo es la idea de que el 'shift left' clásico se construyó para un mundo donde una persona escribía código en un IDE, abría un pull request y un pipeline ejecutaba escáneres sobre ese cambio. Ese mundo, sostiene el autor, se está acabando, señalando la adopción casi universal de herramientas de codificación con IA que reportan compañías como Google y Microsoft. El detalle importante es qué son realmente esas herramientas: un agente de codificación es un proceso que corre en el equipo del desarrollador, con acceso a shell, gestor de paquetes, variables de entorno y credenciales, y a un conjunto de servidores MCP y 'skills' que puede invocar, ejecutando cientos de acciones por tarea que ningún humano llega a leer. Estas herramientas, señala, pueden evitar las abstracciones de rutas autenticadas y las librerías reforzadas que un equipo de plataforma haya construido, y escribir código sin pasar por ellas. Cada una de esas acciones es un punto donde puede producirse un compromiso de la cadena de suministro, una fuga de secretos o un comando destructivo, y todo eso ocurre antes de que exista ningún pull request que escanear.

Como evidencia de que los atacantes ya se han dado cuenta, el artículo repasa varios incidentes. El caso 's1ngularity' de Nx, en agosto de 2025, distribuyó paquetes maliciosos que, según el propio post-mortem de los mantenedores, 'intentaron usar herramientas locales de IA (como Claude y Gemini)' en el equipo de la víctima para buscar información sensible. El gusano Shai-Hulud, que llegó después, identificó otros paquetes mantenidos por un desarrollador comprometido, se inyectó en ellos y los republicó, y en su segunda oleada llegó a comprometer unos 700 paquetes de npm mediante hooks de preinstalación. A esto se suma una investigación presentada en USENIX Security 2025 que encontró tasas de alucinación de paquetes de al menos un 5,2% en modelos comerciales y un 21,7% en modelos de código abierto, sobre 205.474 nombres de paquetes alucinados y únicos, lo que abre la puerta a que un agente instale con total confianza un paquete que no existe y que un atacante se apresure a registrar (lo que en la comunidad se conoce como 'slopsquatting'). La conclusión del autor es que el punto de control de AppSec tiene que trasladarse a donde realmente se crea el código, es decir, al propio agente y al puesto de trabajo donde se ejecuta, y que el diálogo entre el agente de codificación y la plataforma de seguridad debe pasar a ser de agente a agente, porque ya no hay un humano en medio que lea la salida de un escáner y decida.

El artículo dedica su parte central a una demostración con Legit Security, socio de la newsletter, a través de una conversación con su CTO y cofundador, Liav Caspi, y su CMO, Dave Howell. Según Caspi, su enfoque tiene tres frentes: usar IA para encontrar y arreglar los fallos que el análisis estático tradicional no detecta; asegurar el SDLC y el ecosistema de agentes que lo rodea (los propios agentes de codificación, los servidores MCP y las 'skills' que usan los desarrolladores); y envolver todo ello con controles de gobernanza que permitan a los equipos de seguridad fijar políticas y ver qué está ocurriendo. La plataforma funciona, en palabras de Caspi, como una 'mente colmena' ('hive mind'), un cerebro central de AppSec que mantiene un modelo de contexto de seguridad de cada aplicación, descompuesto en componentes como APIs y modelos de datos, y que ejecuta un conjunto de agentes autónomos de detección, respuesta, generación de inventario de componentes (SBOM), triaje y remediación mientras los desarrolladores siguen trabajando. Legit se integra con herramientas como Cursor, Claude Code, Copilot y Codex, y expone su contexto de seguridad mediante un servidor MCP para que un agente de codificación pueda preguntar si un cambio es seguro para desplegar y obtener orientación de remediación sin que un humano tenga que trasladarle los resultados de un escáner.

El agente de triaje es el que se ocupa del problema de 'lluvia frente a inundación': pondera el contexto del código, la alcanzabilidad estática y en tiempo de ejecución, y la puntuación EPSS, con autoridad para rebajar o cerrar hallazgos de bajo riesgo y elevar los que importan; según la propia descripción de Legit, confirma hallazgos, los deduplica y los ordena por explotabilidad. El agente de remediación, por su parte, lee el código, planifica un arreglo y entrega una corrección adaptada al contexto en forma de pull request. Hoy ese agente abre el PR, lo vigila y reacciona ante fallos de compilación o cambios posteriores, pero un humano sigue siendo el responsable último de fusionarlo, y el PR llega al propietario del código correspondiente para revisión y aprobación. Preguntado sobre hacia dónde evoluciona esto, Caspi anticipó que en un año muchos equipos de ingeniería pasarán a esquemas en los que los agentes fusionan código sin intervención humana, algo que el autor cree probable, aunque advierte que la mayoría de responsables de seguridad no están preparados para ese cambio, porque convierte el requisito de 'humano en el bucle' en un parámetro de política, y no en un supuesto de partida.

La segunda mitad de la demostración se centra en VibeGuard, el agente de protección de endpoint de Legit para los puestos de los desarrolladores. Su versión actual ha dejado de operar como una extensión del IDE para instalarse directamente en el propio equipo, de modo que pueda detectar y envolver cualquier agente de codificación en ejecución, actualmente Claude Code, Cursor y Copilot. Según Caspi, 'la seguridad agéntica tiene que ocurrir en el endpoint del desarrollador con el objetivo de potenciar a los agentes, no de bloquearlos', una postura que el autor valida recordando que, en AppSec, cualquier control que ralentice a los desarrolladores acaba siendo esquivado o desinstalado.

En la demostración en vivo dentro de Claude Code, Caspi hizo que el agente instalara Lodash, y VibeGuard interceptó la petición, ya que actúa como proxy de las instalaciones del gestor de paquetes (npm, en este caso) y evalúa la librería antes de que llegue a la máquina, precisamente el tipo de control que habría interceptado el patrón de ataque visto en los incidentes de Nx y Shai-Hulud, o en la investigación sobre paquetes alucinados. Las políticas son granulares: la organización puede decidir, operación por operación, si bloquear, avisar o exigir aprobación, y el desarrollador ve el resultado directamente dentro de la sesión del agente, no en un ticket que llegue una semana después, cuando la vulnerabilidad o el paquete malicioso ya han entrado en producción y los detecta un escáner.

El artículo destaca otros dos controles de VibeGuard. El primero, sobre secretos: los desarrolladores pegan constantemente claves de API y tokens en los prompts de los agentes, y VibeGuard intercepta ese pegado y ofrece en su lugar un método de inyección segura, de modo que el agente puede usar la credencial sin que esta quede almacenada en el historial del prompt, en la transcripción o en cualquier archivo que el agente decida escribir en disco, evitando además que esos secretos se envíen a terceros, como los propios laboratorios de frontera. El segundo es una política de comandos que puede exigir verificación por huella dactilar antes de ejecutar comandos de shell de alto riesgo, con el ejemplo citado de 'gh repo delete', exactamente el tipo de acción que un agente que ha malinterpretado una instrucción, o que ha sido manipulado mediante una inyección de prompt a través de una dependencia envenenada, podría ejecutar sin más. En el plano de gobernanza, VibeGuard ofrece a los administradores una vista centralizada de todos los puestos de desarrollo, incluidos los que todavía no están protegidos, junto con registros de eventos sobre prompts, intentos de bloqueo de secretos y violaciones de política, lo que el autor valora como un paso significativo frente al problema, aún no resuelto, de saber qué desarrolladores están usando qué agentes con qué servidores MCP.

El artículo cierra con recomendaciones para los responsables de AppSec, con independencia del proveedor. En primer lugar, la sesión del agente, y no el pull request, pasa a ser la unidad de trabajo que un programa de seguridad necesita poder ver: si no se puede saber qué instaló un agente, qué ejecutó y qué credenciales se le entregaron, los escáneres del pipeline están auditando el resumen de una transacción que ya ocurrió; la visibilidad del endpoint sobre los agentes de desarrollo debería situarse junto al EDR como control básico, y el autor argumenta que esa responsabilidad debería recaer en AppSec y no en el equipo de endpoint, porque las políticas tratan sobre código, dependencias y secretos. En segundo lugar, el 'humano en el bucle' debe convertirse en una decisión de diseño explícita: hay que definir en qué punto (hallazgo, arreglo, fusión o despliegue) se exige intervención humana, graduarlo según el riesgo y revisarlo a medida que crezca la confianza en las herramientas, porque los equipos que no lo definan acabarán adoptando por defecto lo que traiga el proveedor, y los que impongan 'siempre humano' serán esquivados por desarrolladores que quieran despejar su backlog. En tercer lugar, el argumento de Provos sobre los invariantes gana peso cuanto más código escriben los agentes: la alcanzabilidad, el control de salida de red, las librerías reforzadas que se indique usar al agente y las listas blancas de paquetes aplicadas en el propio puesto de trabajo son los controles que siguen funcionando cuando ni el desarrollador ni el revisor son humanos, y las barreras puestas en el momento de creación resultan, en general, más baratas que el triaje posterior.

El autor concluye que la dirección del sector le parece clara: la IA ha abaratado el descubrimiento, la remediación se está delegando a agentes, y el código en sí lo escribe cada vez más un proceso que ningún humano supervisa directamente. Considera que la seguridad se enfrenta a la disyuntiva entre situarse donde ahora ocurre realmente el trabajo o seguir añadiendo controles a un pipeline que ve una porción cada vez menor de lo que importa, y sostiene que los equipos que están construyendo puntos de control en el endpoint del desarrollador y en interfaces de agente a agente dentro de sus plataformas de AppSec están, en su opinión, más cerca de donde se dirige el sector que quienes siguen afinando sus escáneres de pull requests. Cabe señalar que este artículo incluye una colaboración/demostración con un proveedor (Legit Security), que además figura como socio comercial de la newsletter del autor, un dato relevante a la hora de valorar el tono favorable hacia ese producto concreto.