Cuando el tiempo de explotación es negativo: qué hacer con tu patch SLA

Hay un número en M-Trends 2026 que debería reescribir cómo pensamos la gestión de vulnerabilidades en toda la industria: el mean time-to-exploit estimado es de menos siete días. Negativo. La explotación empieza, en promedio, antes de que exista el parche.

Para dimensionar el cambio: en 2018 ese mismo número era de 63 días. Los equipos de seguridad tenían cerca de dos meses entre el disclosure de una vulnerabilidad y su explotación para identificarla, priorizarla, testear el fix y desplegarlo. En 2024 la métrica cruzó el cero. Hoy se ubica en menos siete. La ventana no se achicó: se invirtió.

Qué significa un tiempo de explotación negativo

Un tiempo de explotación negativo significa que, en promedio, los atacantes están explotando una vulnerabilidad antes de que el fabricante publique el parche que la corrige. El modelo mental tradicional -se publica el CVE, empieza la carrera para parchear antes de que alguien lo aproveche- asume que existe una ventana de ventaja para el defensor. Ese supuesto dejó de sostenerse. Cuando la explotación precede al parche, no hay carrera que ganar dentro del marco del parcheo: la exposición ya está abierta antes de que tengas algo que aplicar.

Lo veo todas las semanas. Cuando corremos testing basado en cambios sobre fintechs y procesadores de pagos en Latinoamérica, la distancia entre "se publicó el CVE" y "ese CVE ya está corriendo en tráfico adversario" se colapsó a casi cero.

Tres datos que confirman el cambio

No es una métrica aislada ni una lectura optimista de una sola fuente. Tres datos independientes apuntan en la misma dirección.

El primero: IBM X-Force 2026 reporta que el 40% de los incidentes observados empezaron con la explotación de una vulnerabilidad, lo que la ubica como la causa principal de los ataques. El segundo: según los datos de VulnCheck sobre tendencias de explotación, el 28.3% de los CVEs que fueron explotados se weaponizaron dentro de las 24 horas de su disclosure público. El tercero no es una cifra, sino un cambio estructural: el pipeline de research-to-weaponize, que solía tomar semanas, hoy opera en mercados de exploits acelerados por IA, muchas veces antes de que el aviso llegue a tu equipo.

Lo que la mayoría de los análisis pasa por alto es que esto no se trata de atacantes más sofisticados. Se trata de industrialización. El pipeline se volvió una cadena de montaje.

Por qué tu patch SLA de 72 horas ya no alcanza

El patch SLA -el Service Level Agreement que define en cuánto tiempo una organización se compromete a aplicar un parche- de 72 horas se calibró para un mundo en el que ese pipeline tomaba dos semanas. Ese mundo terminó. No porque la política esté mal escrita, sino porque mide contra una ventana que ya no existe.

Cuando me siento con CISOs, la brecha que veo con más frecuencia no está en la política de parcheo en sí. Está entre la política y la realidad operativa, y es justamente la brecha en la que los atacantes ya están adentro. Por eso la pregunta honesta no es cuál es tu SLA, sino otra: ¿cuál es tu mean time to patch real sobre un CVE en tu inventario expuesto externamente? No el del SLA. El número real. Si no lo conocés, no podés cerrarlo.

Qué hacer cuando el atacante llega antes que el parche

Si la explotación precede al parche, la defensa no puede depender de la velocidad de parcheo. Tiene que apoyarse en saber, de forma continua, qué hay expuesto y cómo podría ser explotado, sin esperar a que se publique un aviso. Eso corre la conversación desde la gestión reactiva de parches hacia la validación continua de la exposición real.

En Strike pasamos el último año argumentando que la validación híbrida continua dejó de ser un feature: es el nuevo piso. Cuando los atacantes trabajan antes de que se abra tu ventana de parcheo, tu testing también tiene que hacerlo. No esperan tu patch window. Están trabajando antes de que se abra.

‍