La paradoja de la divulgación de vulnerabilidades: Por qué un parche más rápido no puede escapar de los ataques generados por IA

Durante décadas, la gestión de parches se basó en una sola suposición: si avanzabas lo suficientemente rápido, vencías a los atacantes. El reporte M-Trends 2026 de Mandiant muestra que la raza terminó. La vulnerabilidad promedio ahora se explota siete días antes de que exista siquiera una solución.

El contraste con el pasado reciente es evidente. En 2018, los defensores tenían unos dos meses después de que una vulnerabilidad se hiciera pública antes de que alguien intentara explotarla: el momento de probar un parche y desplegarlo antes de que alguien llamara a la puerta. Esa ventana ahora se volvió negativa.

El Reporte Global de Amenazas 2026 de CrowdStrike respalda esto, concluyendo que el 42% de las vulnerabilidades explotadas fueron atacadas antes incluso de ser divulgadas públicamente.

Me senté a discutir estos hallazgos con Jason Garbis, fundador de Numberline Security y copresidente del Grupo de Trabajo Zero Trust en la Cloud Security Alliance, para un episodio reciente del podcast The Segment .  

Una vez que una vulnerabilidad se hace pública, argumentó, los atacantes ya no necesitan buscar el fallo en absoluto. La propia divulgación les proporciona un plano, y construir un exploit a partir de un aviso publicado requiere mucho menos trabajo que encontrar la debilidad desde cero.  

Ese cambio es la razón por la que la larga obsesión de la industria de la seguridad por la velocidad de parcheo está persiguiendo la meta equivocada. Los equipos que se mantienen en esta nueva línea temporal comparten un rasgo. Asumen que serán vulnerados en algún punto entre la divulgación y el parche, y ya limitaron hasta dónde puede llegar esa brecha.

Cuando el aviso de parche se convierte en el plano del atacante

Todo proceso responsable de divulgación existe por una buena razón.  

Los proveedores necesitan informar a los clientes de lo que está roto para poder arreglarlo, y los reguladores lo exigen cada vez más. Pero esa misma transparencia ahora funciona en ambos sentidos.  

En el momento en que un CVE se hace público, los atacantes no necesitan descifrar un misterio. Solo tienen que leer el aviso. Luego comparan el código parcheado con la versión vulnerable. A partir de esa diferencia, pueden construir un exploit funcional.

Investigaciones de la Iniciativa de Seguridad en IA de la Cloud Security Alliance muestran hasta qué punto este proceso fue automatizado. Los sistemas de IA multiagente diseñados para reproducir vulnerabilidades reveladas recrearon aproximadamente la mitad de todos los CVEs publicados en los últimos dos años, muchos con exploits funcionales, a un costo medio inferior a 3 dólares por intento.  

Lo que antes requería un ingeniero inverso hábil y días de esfuerzo silencioso, ahora se hace por unas monedas. Tarda aproximadamente lo mismo que leer el aviso dos veces.

Este es el mecanismo que Jason y yo discutimos en el podcast. Un atacante con acceso a un modelo de IA de vanguardia que escanea repositorios de código en busca de fallos no descubiertos supone un riesgo real. 

Pero la amenaza más inmediata es más sencilla. Los atacantes esperan la divulgación y luego se apresuran a construir el exploit antes de que los defensores terminen de validar y desplegar el parche.  

La divulgación se convirtió discretamente en reconocimiento, y la mayoría de los programas de gestión de parches nunca se crearon para sobrevivir a eso.

El tsunami de parches post-Mito

Jason tiene un término creativo para lo que ve que ocurrirá en un futuro cercano: un tsunami de parches.

Los modelos de IA Frontier están ahora mostrando vulnerabilidades y provocando actualizaciones de seguridad a un volumen y velocidad que la mayoría de los equipos nunca enfrentaron. El debate sobre los modelos de clase Mythos y el Proyecto Glasswing solo avivó esa conversación.  

Pero la opinión de Jason es que no importa cuánto del bombo inicial fuera marketing. Estos modelos siguen mejorando a la hora de encontrar fallos, y los defensores deben preparar para esa realidad sin importar el ritmo.

Los números lo respaldan. Las publicaciones globales de CVE superaron las 48.000 en 2025, un aumento del 20% respecto al año anterior, según un análisis de datos oficiales de CVE realizado por el investigador de Cisco Jerry Gamblin. Su seguimiento a mitad de año muestra que la curva se está volviendo vertical: solo la primera mitad de 2026 produjo más de 35.000 CVEs, un aumento de casi un 50% respecto al mismo periodo del año anterior. Eso es un CVE nuevo cada 7,4 minutos.  

Los proveedores de software comercial también están comprimiendo la duración que soportan versiones antiguas, lo que obliga a ciclos de actualización más rápidos en toda la compañía.  

Las bibliotecas de código abierto también se están convirtiendo en una fuente creciente de exposición. Jason señaló que a menudo tienen mucho menos rigor en cuanto a empaquetado y versionado que el software comercial. Depende de ellos mucho software empresarial personalizado, a veces sin haber tocado en años.

Jason argumentó que los fundamentos de la seguridad de la información no cambiaron. La industria ya sabe cómo defender de todas las categorías de ataques a las que se enfrenta hoy en día.  

Lo que está cambiando es el volumen y la velocidad con la que llegan los riesgos conocidos. Ese cambio está exponiendo a equipos que nunca desarrollaron la disciplina necesaria para seguir el ritmo, incluso antes de que la IA entrara en escena.

Hasta dónde puede extender una brecha es la métrica que importa

Si la velocidad de parcheo por sí sola no puede superar un tiempo negativo para explotar, los líderes de seguridad necesitan una métrica diferente. La verdadera pregunta es hasta dónde puede llegar un atacante una vez que entra.  

Jason ofreció un ejemplo concreto de su trabajo de consultoría. Imagina una aplicación financiera ejecutar en una red empresarial plana, donde cualquiera de los 5.000 empleados y dispositivos puede acceder directamente a ella. Ahora imagina esa misma aplicación restringida a las aproximadamente 200 personas que realmente trabajan en finanzas. 

La vulnerabilidad aún necesita parcheo de todas formas. Pero la población que podía explotarla antes de que aterrizaran las zonas se redujo más de un 95%.

Ese es el caso de tratar la segmentación como un control fundamental. No elimina la necesidad de parchear ni exige una política perfecta y detallada desde el primer día. La segmentación de grano grueso, aplicada en tus sistemas de mayor valor, sigue aportando beneficios.  

Con la segmentación adecuada, una vulnerabilidad que podría haber convertido en una catástrofe importante se convierte en un pequeño incidente que tu equipo puede manejar en una tarde.

La guía en sí fue constante durante años. Lo que cambió es el costo de ignorarlo, dado lo rápido que una nueva revelación puede convertir ahora en un exploit funcional.

Tres movimientos que merece la pena hacer antes de tu próximo ciclo de divulgación

De mi conversación con Jason surgieron algunos pasos concretos. Animaría a todo líder de seguridad a sopesar estos aspectos con su hoja de ruta actual.

Haz un inventario real de lo que está en marcha y quién debería acceder a él

Jason fue enfático en esto. La tecnología de segmentación solo aporta valor cuando se le proporcionan datos precisos y legibles por máquina sobre tus cargas de trabajo y las identidades que necesitan acceso a ellas. Saltar este paso es la forma más rápida de acabar con una política que en el papel parece buena y que se interrumpe en la producción.

Segmenta tus sistemas de mayor valor ahora, aunque sea de forma tosca

Esperar una política perfecta y completamente mapeada antes de actuar es la parálisis del análisis contra la que Jason advirtió directamente. Un primer paso aproximado de tus activos críticos supera a un plan bellamente documentado que nunca se publica.

Pon un temporizador de refresco en tus sistemas heredados

Jason recomienda exigir que todos los sistemas nuevos sigan la gobernanza moderna desde el primer día. Cada sistema existente debería recibir un ciclo obligatorio de reconstrucción o revisión, por ejemplo cada 12 a 18 meses. Repartir ese trabajo por el calendario evita que se convierta en un montón que ningún equipo logra hacer.

El momento de actuar es antes de la siguiente revelación, no después

En junio, la Agencia de Ciberseguridad e Infraestructura (CISA) oficializó esta política. La Directiva Operativa Vinculante 26-04 ahora exige a las agencias federales remediar las vulnerabilidades más peligrosas (expuestas públicamente, explotadas activamente y automatizables) en un plazo de tres días, por debajo del estándar anterior de dos semanas. CISA señaló directamente la IA como la razón, señalando que está aumentando enormemente el ritmo de descubrimiento de vulnerabilidades tanto para atacantes como para defensores.

La directiva solo obliga a las agencias federales, pero CISA anima al sector privado a adoptar el mismo enfoque. La expectativa básica de la industria sobre el tiempo de respuesta ya fue reescrita.

La buena noticia es que nada de esto requiere reinventar tu programa de seguridad desde cero. Requiere aceptar que una brecha que ocurre en algún punto intermedio entre la divulgación y el parche es ahora el escenario para planear. Y requiere construir segmentación alrededor de tus sistemas más importantes, de modo que cuando ocurra una brecha, cueste una tarde en lugar de un titular.  

Los equipos que ahora tratan esto como algo urgente, mientras aún hay diferencia entre el panorama actual de amenazas y lo que llegue con la próxima generación de modelos, son los que seguirán contando una buena historia dentro de un año. Esperar un momento más limpio es una apuesta que los datos ya no soportan.

Escucha el episodio completo de The Segment: Un pódcast de liderazgo Zero Trust en Apple Podcasts,  Spotify, o Nuestro sitio web.