El volumen de hallazgos dejó de ser una buena señal por sí sola. Hoy el punto está en otro lado: decidir qué corregir primero, con qué urgencia y con qué nivel de control sobre la operación. La explotación de vulnerabilidades sigue entre las rutas de intrusión más frecuentes, y el margen entre exposición y abuso suele ser corto.
Las últimas semanas volvieron a dejarlo claro. CISA siguió incorporando vulnerabilidades activamente explotadas a su catálogo KEV, incluyendo casos recientes en tecnologías tan distintas como Drupal Core, Trend Micro Apex One, Langflow, Microsoft Defender, Cisco Catalyst SD-WAN, PAN-OS, cPanel/WP2, SimpleHelp y ConnectWise ScreenConnect.
No todos esos casos tienen el mismo impacto ni afectan el mismo tipo de activo, pero apuntan a un problema operativo común: cuando una vulnerabilidad ya está siendo explotada, la prioridad deja de depender solo del scoring técnico y pasa a depender de la exposición real.
Ese patrón tiene cifras concretas. Según M-Trends 2026, basado en más de 500.000 horas de investigaciones de respuesta a incidentes realizadas por Mandiant durante 2025, los exploits fueron el vector de acceso inicial más frecuente por sexto año consecutivo, presentes en el 32% de las intrusiones investigadas.
El mismo reporte muestra otro dato relevante para cualquier equipo de defensa: la ventana mediana entre el acceso inicial y el traspaso a un segundo actor cayó desde más de ocho horas en 2022 a solo 22 segundos en 2025. Con ese ritmo, un backlog tratado como una lista plana deja de ser una ineficiencia administrativa y se convierte en un problema de control.
El problema actual no es detectar vulnerabilidades
Muchos programas de Vulnerability Management se traban exactamente ahí. Detectan bien, pero priorizan con una lógica demasiado rígida. Acumulan hallazgos, abren tickets y distribuyen urgencia casi por reflejo, como si todas las vulnerabilidades críticas o altas compitieran en el mismo plano.
En la práctica, una falla severa en un activo poco expuesto y sin función sensible no pesa igual que una vulnerabilidad explotada activamente en una plataforma accesible desde Internet, una consola de administración, un sistema de soporte remoto o un componente que sostiene procesos relevantes del negocio.
El problema no suele ser falta de datos. Hay escáneres, reportes, CVSS, inventarios parciales, avisos de fabricantes, catálogos públicos, inteligencia de amenazas y tickets abiertos.
La dificultad aparece cuando esa información no se transforma en una decisión operativa clara.
Por qué el CVSS ya no es suficiente para priorizar
Una vulnerabilidad puede tener una puntuación alta y aun así no ser la primera en la fila. Otra puede parecer menos grave en el papel, pero cambiar completamente de prioridad si afecta un activo expuesto, sin controles compensatorios, con señales de explotación o con dependencia directa de servicios críticos.
Ese punto se vuelve más evidente cuando se mira la proporción entre volumen y explotación real. Qualys Threat Research Unit estimó que, en 2025, solo 357 de 48.172 vulnerabilidades fueron explotadas e incorporadas al catálogo CISA KEV, equivalente a 0,74%.
El dato no reduce la importancia de corregir; reduce la utilidad de tratar todo el backlog con la misma urgencia.
Si una fracción menor de las vulnerabilidades observadas concentra el abuso confirmado, la pregunta operacional no puede limitarse a cuántos hallazgos existen. Debe apuntar a:
- Cuáles tienen una ruta plausible hacia explotación
- Qué activos afectan
- Qué nivel de exposición tienen
- Qué controles compensatorios existen en el entorno
En otras palabras, una vulnerabilidad crítica no siempre representa el mayor riesgo operativo.
El catálogo KEV cambió la forma de priorizar vulnerabilidades
Los casos recientes apuntan en esa dirección. En abril y mayo, el catálogo KEV volvió a incluir vulnerabilidades asociadas a:
- Plataformas de administración
- Soluciones de seguridad
- Componentes de infraestructura
- Aplicaciones expuestas
- Herramientas utilizadas para operación remota
También siguen siendo relevantes casos como SAP NetWeaver CVE-2025-31324, una falla crítica en Visual Composer Metadata Uploader que permitía carga de archivos maliciosos sin autenticación y que fue incluida en el catálogo KEV tras observarse explotación activa.
El producto cambia, pero el patrón se mantiene: los atacantes buscan activos accesibles, con valor operativo y con una ruta práctica hacia ejecución, persistencia o movimiento lateral.
La velocidad de explotación está superando la remediación
La misma tensión aparece en la brecha entre velocidad de explotación y velocidad de remediación.
Qualys cita un crecimiento de 6,5 veces en el volumen de vulnerabilidades durante los últimos cuatro años, un tiempo mediano de explotación de 18 días y un MTTR mediano de 67 días.
La lectura operacional es clara: si la explotación avanza más rápido que la corrección, la priorización deja de ser un ejercicio de ordenamiento y pasa a ser una forma de administrar exposición bajo restricción. Con esa velocidad, la priorización lenta deja de ser solo un problema de eficiencia.
Si una exposición crítica se mantiene abierta en un activo relevante, el tiempo empieza a jugar en contra.
No basta con saber que existe una vulnerabilidad, hay que saber:
- Si está explotada
- Si el activo está expuesto
- Si el control compensatorio realmente cubre el riesgo
- Si la remediación tiene dueño, plazo y trazabilidad
La diferencia entre conocer un hallazgo y gestionarlo hasta el cierre sigue siendo uno de los puntos más débiles en muchos programas de seguridad.
Cómo la IA está acelerando el descubrimiento de vulnerabilidades
La presión no viene solo desde la explotación conocida. También está cambiando la forma en que se descubren, validan y encadenan vulnerabilidades.
Anthropic presentó Project Glasswing en abril de 2026 como una iniciativa para usar Claude Mythos Preview en la identificación de vulnerabilidades sobre software crítico, junto a organizaciones como AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA y Palo Alto Networks.
En su actualización del 22 de mayo, Anthropic indicó que el proyecto ya había encontrado más de diez mil vulnerabilidades de severidad alta o crítica junto a sus partners. Ese punto importa menos por el nombre del modelo y más por lo que anticipa.
Cloudflare, participante de Project Glasswing, describió capacidades relevantes de Mythos Preview, incluyendo:
- Construcción de cadenas de explotación
- Generación de pruebas de explotación
- Validación de si una falla es realmente explotable
En términos prácticos, eso reduce la distancia entre encontrar una debilidad y demostrar una ruta de abuso.
Para los equipos de seguridad, el efecto es directo: si el descubrimiento y la validación se aceleran, la priorización manual basada en severidad estática queda aún más tensionada.
Qué debería considerar una priorización efectiva
Por eso la conversación seria sobre vulnerabilidades cambió de eje. Escanear más ayuda solo si el resultado permite decidir mejor. Lo relevante es saber:
- Qué activos están más expuestos
- Cuáles sostienen procesos sensibles
- Qué hallazgos cambiaron de estado
- Cuáles tienen señales de explotación
- Qué vulnerabilidades fueron incorporadas al catálogo KEV
- Qué correcciones pueden ejecutarse sin comprometer la continuidad operacional
Sin esa capa de criterio, la gestión se reduce a mover registros entre herramientas. Hay actividad, pero no necesariamente reducción de riesgo.
El rol de un MSOC en la gestión de vulnerabilidades
Un MSOC bien operado aporta precisamente esa capa de decisión. En la práctica, significa ordenar la exposición con contexto:
- Criticidad del activo
- Accesibilidad
- Explotación conocida
- Dependencia operativa
- Cobertura de controles
- Ventanas de cambio
- Factibilidad de remediación
También implica distinguir cuándo una corrección debe entrar por una vía acelerada, cuándo requiere validación previa y cuándo corresponde absorberla dentro de un ciclo regular de higiene.
Esa disciplina tiene más valor que cualquier ranking automático cuando el objetivo es reducir exposición sin perder control sobre la operación.
La telemetría también cambia la calidad de la priorización. Una vulnerabilidad no vive aislada, está asociada a un activo, una red, una zona, una función de negocio y una historia reciente de actividad.
Cuando el equipo cruza esa exposición con señales del entorno, como cambios de superficie, intentos de conexión, comportamiento anómalo, activos fuera de cobertura o fallas que reaparecen después de haber sido corregidas, la prioridad deja de depender solo de un número. Pasa a ser una decisión defendible frente a operaciones, auditoría y gerencia.
Cómo medir la madurez de un programa de Vulnerability Management
Un programa maduro de gestión de vulnerabilidades no debería medirse solo por la cantidad de hallazgos detectados en el mes. Esa cifra puede crecer por mejores escaneos, por ampliación de cobertura o simplemente por deuda acumulada.
Tiene más valor saber:
- Cuántas exposiciones críticas siguen abiertas
- Cuántas quedaron fuera de la ventana de remediación
- Cuántos activos sensibles permanecen rezagados
- Qué parte del backlog requiere tratamiento acelerado
- Cuál es el MTTR real
- Cuántas vulnerabilidades reaparecen después de ser corregidas
Ese cambio parece menor, pero modifica la conversación con las áreas técnicas y con la dirección. También permite demostrar avance real, no solo actividad.
Gestión de vulnerabilidades orientada a reducción de exposición
En Widefense abordamos ese problema desde la operación. Dentro del servicio MSOC, la gestión de vulnerabilidades no funciona como un entregable aislado ni como una rutina de escaneo. Es una capacidad continua orientada a:
- Ordenar exposición
- Decidir prioridades
- Coordinar remediación
- Mantener trazabilidad
- Reducir deuda
- Escalar riesgos cuando corresponde
Ese enfoque ayuda a reducir ruido y sostener una conversación más útil, porque aterriza el riesgo en decisiones concretas. Ninguna organización va a corregir todo al mismo tiempo. Siempre habrá restricciones, ventanas, dependencias y backlog. La diferencia está en cómo se administra esa realidad.
Un servicio que solo enumera vulnerabilidades termina corriendo detrás del problema. Uno que las contextualiza, las conecta con telemetría y las sigue hasta el cierre trabaja con mayor control. En el escenario actual, eso tiene más peso que cualquier consola llena de hallazgos.
Preguntas frecuentes sobre gestión de vulnerabilidades
¿Qué es el catálogo KEV de CISA?
El catálogo KEV (Known Exploited Vulnerabilities) de CISA reúne vulnerabilidades que ya presentan evidencia de explotación activa en el mundo real. Se utiliza como referencia para priorizar remediaciones urgentes.
¿Por qué el CVSS no siempre refleja el riesgo real?
Porque el CVSS mide severidad técnica, pero no necesariamente considera exposición real, criticidad del activo, accesibilidad desde Internet o explotación activa.
¿Qué significa que una vulnerabilidad esté siendo explotada activamente?
Significa que existen actores utilizando esa falla para comprometer sistemas reales, aumentando significativamente la urgencia de remediación.
¿Qué hace un MSOC en la gestión de vulnerabilidades?
Un MSOC ayuda a contextualizar hallazgos, priorizar según riesgo operativo, coordinar remediaciones y dar seguimiento continuo a la exposición.
¿Qué métricas sirven para medir un programa de Vulnerability Management?
Algunas métricas relevantes son:
- MTTR
- Exposiciones críticas abiertas
- Vulnerabilidades fuera de SLA
- Backlog crítico
- Reincidencia de vulnerabilidades
- Cobertura de activos sensibles.
¿Quieres saber cómo el enfoque de Widefense puede ayudarte a priorizar mejor y reducir exposición relevante en tu organización? Hablemos.