Blog
CTEM frente a gestión de vulnerabilidades: qué cambia
La mayoría de las organizaciones que dicen haber adoptado CTEM han hecho una de dos cosas: comprar un panel nuevo para su escáner actual, o añadir «exposición» al nombre del equipo de gestión de vulnerabilidades. Ninguna de las dos es un error, pero ninguna es el cambio que describe el modelo CTEM de Gartner.
La respuesta corta
La gestión de vulnerabilidades encuentra y corrige fallos de software conocidos en activos que ya se tienen inventariados. CTEM es un ciclo más amplio y repetitivo: define el alcance según el impacto en el negocio, encuentra exposiciones que no son CVE, las ordena por probabilidad y consecuencia, demuestra que las importantes son explotables y se asegura de que alguien las corrija. La gestión de vulnerabilidades pasa a ser una entrada de CTEM, no un rival.
Qué mide cada uno
La gestión de vulnerabilidades mide el estado del software en los hosts que el escáner alcanza: cuántas vulnerabilidades hay, cuán graves son y cuánto tiempo llevan abiertas. CTEM mide la exposición: de cuántas maneras podría un atacante llegar a algo que le importa al negocio, cuántas de ellas están demostradas y con qué rapidez se cierran. Una cuenta hallazgos. La otra cuenta resultados.
La gestión de vulnerabilidades cuenta CVE. El programa CVE existe para “identify, define, catalog publicly disclosed cybersecurity vulnerabilities” (identificar, definir y catalogar vulnerabilidades de ciberseguridad divulgadas públicamente), así que todo lo que no sea un fallo divulgado públicamente nunca aparece en el recuento. Una cuenta de servicio con privilegios excesivos, un subdominio olvidado, una integración SaaS con acceso de escritura y un bucket de almacenamiento mal configurado son todos exposiciones. La mayoría nunca recibirá un CVE, porque son problemas de configuración e identidad y no defectos de software.
CTEM las cuenta todas, y no se queda en contar. Las medidas que importan son las exposiciones validadas que siguen abiertas y el tiempo que se tarda en cerrarlas, y por eso las métricas que la dirección leerá de verdad se ven tan distintas de un informe del escáner.
Alcance: activos frente a rutas de ataque
El alcance de la gestión de vulnerabilidades suele ser una lista de activos: todos los servidores, equipos y contenedores hacia los que se apunta el escáner. El alcance de CTEM es una porción del negocio, como un proceso que genera ingresos o la superficie de ataque externa, acordada con la persona que responde de ella. Definir el alcance es una fase en sí misma, y el escáner no tiene nada equivalente.
Un alcance basado en activos trata la máquina virtual de pruebas de un desarrollador y una base de datos de pagos como miembros iguales de un mismo inventario. Un alcance basado en el negocio parte de la pregunta «¿qué haría daño si se detuviera o se filtrara?» y retrocede hasta los sistemas, las identidades y los terceros que hay en el camino hacia ello.
También decide qué se encuentra. Un escáner ve lo que puede alcanzar. Un ciclo con alcance definido pregunta qué fuentes ven ese alcance (inventario cloud, sistemas de identidad, DNS, registros de certificados, la CMDB) y persigue las lagunas.
No hace falta definir el alcance de todo el parque. Una porción acotada con un responsable de negocio con nombre basta para un primer ciclo, y el plan de 90 días se construye exactamente en torno a eso.
Priorización: severidad frente a probabilidad e impacto
La gestión de vulnerabilidades suele ordenar por CVSS. CTEM ordena según si una exposición es explotable en el entorno propio, si se está explotando ahora y qué alcanza un atacante si la usa. CVSS pasa a ser una entrada más entre varias. Responde a «cuán grave podría ser esto en general», no a «cuán grave es aquí».
FIRST, que mantiene CVSS, es explícito al respecto. Su guía de usuario dice que las puntuaciones base de CVSS “are designed to measure the severity of a vulnerability and should not be used alone to assess risk” (están diseñadas para medir la severidad de una vulnerabilidad y no deben usarse por sí solas para evaluar el riesgo). La puntuación base ignora la amenaza y el entorno. Un CVSS 9.8 en una máquina de pruebas aislada queda por debajo de un CVSS 6 en la ruta hacia un controlador de dominio.
Dos fuentes públicas ayudan a responder a «¿se está explotando?»:
- El catálogo de vulnerabilidades explotadas conocidas (CISA KEV). CISA lo describe como “the authoritative source of vulnerabilities that have been exploited in the wild” (la fuente autorizada de vulnerabilidades que se han explotado en la práctica) y recomienda usarlo como entrada del marco de priorización de la gestión de vulnerabilidades. Si algo figura en él, alguien ya lo ha usado.
- EPSS. El Exploit Prediction Scoring System de FIRST estima la probabilidad de que un CVE publicado se explote en la práctica en los próximos 30 días, y sirve para concentrar el esfuerzo limitado de remediación donde los ataques son más probables. Ordena la probabilidad entre CVE. No sabe cómo es su red.
Ninguna de las dos conoce el negocio. La alcanzabilidad y el impacto en el negocio salen del trabajo propio de definición del alcance y descubrimiento: ¿puede un atacante llegar al sistema y qué hay detrás? La evidencia de explotación indica qué es urgente en el mundo. El contexto propio indica qué es urgente aquí. Ordenar exige ambas cosas, y una hoja de cálculo es una buena forma de empezar.
El Data Breach Investigations Report de 2025 de Verizon encontró que la explotación de vulnerabilidades fue el vector de acceso inicial en el 20 % de las brechas con vector conocido (excluidos el error y el mal uso), y que solo alrededor del 54 % de las vulnerabilidades en dispositivos perimetrales que estudió se remediaron por completo, con una mediana de 32 días (Verizon, 2025 DBIR).
Validación: demostrarlo
La gestión de vulnerabilidades se detiene en «lo dice el escáner». CTEM valida: comprueba si una exposición concreta es realmente explotable desde una posición realista de atacante, y qué alcanza, antes de que nadie se comprometa a remediarla. El resultado es una ruta demostrada o una rebaja documentada, y ambos son útiles.
La validación es la fase que más se salta, porque exige un esfuerzo técnico real. Puede ser una prueba de penetración acotada sobre los diez elementos principales, un intento de explotación seguro, un análisis de rutas de ataque o una simulación que compruebe si salta la detección. No es lo mismo que un programa de simulación de brechas y ataques (BAS), que prueba los controles frente a técnicas conocidas; BAS frente a validación CTEM explica dónde se solapan y dónde no.
Saltarse la validación deja las prioridades de remediación apoyadas en una puntuación en vez de en una prueba. Los equipos parchean elementos que nunca fueron alcanzables y gastan buena voluntad en tickets que acaban discutidos, mientras una exposición de puntuación baja que se encadena con algo valioso queda al final de la cola.
Movilización: quién lo corrige
La gestión de vulnerabilidades suele terminar con un informe o una cola de tickets y la esperanza implícita de que el equipo adecuado se haga cargo. La última fase de CTEM, la movilización, convierte el cierre en trabajo de alguien con nombre: un responsable por clase de exposición, una fecha acordada, una vía para las excepciones y un paso de verificación una vez aplicada la corrección.
La carencia aquí es más organizativa que técnica. Seguridad encuentra la exposición, pero la corrigen los equipos de infraestructura, plataforma, aplicaciones e identidad, que tienen sus propias prioridades. Una lista de diez elementos validados y relevantes para el negocio, con un alcance firmado detrás, es más difícil de ignorar que una lista de hallazgos en bruto.
Elementos prácticos de la movilización:
- Responsables de la corrección nombrados al definir el alcance, no descubiertos al abrir el ticket.
- Niveles de servicio por clase de exposición, no una cifra única para todo. Una interfaz de administración expuesta y un certificado de pruebas caducado no tienen la misma urgencia.
- Una vía de decisión para la aceptación del riesgo, de modo que «no lo vamos a corregir» sea una decisión registrada, tomada por quien tiene autoridad para tomarla.
- Nueva prueba. Un ticket cerrado no es una exposición cerrada. Verificar.
CTEM y gestión de vulnerabilidades, lado a lado
Los dos no se oponen. CTEM incluye la gestión de vulnerabilidades y añade fases a su alrededor. La tabla siguiente los compara en ocho dimensiones, desde qué cuenta como unidad de trabajo hasta qué se comunica a la dirección, para ver qué diferencias cubre ya el programa propio.
| Dimensión | Gestión de vulnerabilidades | CTEM |
|---|---|---|
| Unidad de trabajo | Una vulnerabilidad, normalmente un CVE | Una exposición, incluidas configuraciones erróneas, identidades y acceso de terceros |
| Alcance | Activos que el escáner puede alcanzar | Una porción acordada con el negocio, definida en una fase de alcance |
| Descubrimiento | Escaneos programados | Varias fuentes conciliadas, persiguiendo lo desconocido |
| Priorización | Sobre todo severidad CVSS | Explotabilidad, explotación activa, alcanzabilidad e impacto en el negocio |
| Prueba | Hallazgo del escáner | Validada como explotable, o rebajada con evidencia |
| Responsabilidad | Seguridad abre tickets | Responsables de la corrección nombrados desde el principio, con cierre seguido y verificado |
| Ritmo | Ciclo de escaneo y ventanas de parcheo | Ciclo repetitivo con un alcance definido en cada pasada |
| Qué se informa | Recuentos y antigüedad de hallazgos | Exposiciones validadas abiertas y tiempo hasta el cierre verificado |
Qué conservar de un programa de gestión de vulnerabilidades
Casi todo. Sigue habiendo que parchear. Sigue habiendo que mantener el inventario de activos. El escáner sigue ejecutándose, y su salida es la mayor fuente de descubrimiento. CTEM se sitúa por encima de todo esto y decide adónde va el esfuerzo. Si la capacidad de remediación es de doscientas correcciones al mes, CTEM es el proceso que elige las doscientas correctas.
Conserve también a las personas. Quien dirige hoy la gestión de vulnerabilidades conoce el parque y sabe qué equipos responden a los tickets, y es la persona natural para liderar el programa en un primer ciclo.
Lo que hay que cambiar es menos de lo que sugieren la mayoría de los proveedores: una conversación sobre el alcance, más fuentes que el escáner, ordenar por evidencia de explotación y alcanzabilidad, validar la parte alta de la lista y nombrar responsables de la corrección. Es primero un cambio de proceso y solo después una cuestión de herramientas.
Si finalmente se compra algo, la guía de herramientas explica qué cubre cada categoría, y el directorio de proveedores recoge lo que afirman productos concretos.
Una prueba de un ciclo
Tome la lista de remediación del mes pasado. Para cada elemento, pregunte: ¿podríamos mostrar la ruta de ataque hacia algo que le importe al negocio? ¿Alguien verificó que era explotable? ¿Se nombró al responsable de la corrección y se hizo seguimiento del cierre? Si la respuesta es mayoritariamente no, el programa es gestión de vulnerabilidades con otro nombre. Es un buen punto de partida. Solo que no es la meta.
Cómo empezar
Empiece por un alcance acotado, no por una plataforma. Elija una porción de sistemas con un responsable de negocio evidente, concilie las fuentes que la ven, ordene las exposiciones a mano, valide las diez principales y haga seguimiento hasta el cierre verificado. Informe de lo ocurrido.
Tres pasos siguientes prácticos:
- Haga la comprobación rápida de dos minutos para una primera lectura de la fase más débil.
- Use la evaluación para puntuar las cinco fases y ver cuál está más lejos de donde debe estar.
- Siga Cómo iniciar un programa CTEM en 90 días para el plan semana a semana, y consulte el modelo de madurez para ver qué aspecto tiene el nivel «Definido».
Preguntas frecuentes
¿CTEM es solo gestión de vulnerabilidades con otro nombre?
No, aunque a menudo se implanta así. La diferencia es el proceso que rodea al escáner: alcance basado en el negocio, fuentes más allá del escáner, orden por explotabilidad e impacto, validación y responsables con nombre para las correcciones. Si no existe nada de eso, lo que hay es gestión de vulnerabilidades, que es una base sólida y no un fracaso.
¿Hace falta sustituir el escáner de vulnerabilidades para hacer CTEM?
No. El escáner se queda como fuente de descubrimiento y como registro de los fallos de software. Lo que cambia es lo que ocurre con su salida. La mayoría de los primeros ciclos se ejecutan con las herramientas existentes.
¿CVSS sigue importando con CTEM?
Sí, como una entrada más. FIRST dice que las puntuaciones base no deben usarse por sí solas para evaluar el riesgo. Combine la severidad con evidencia de explotación como el catálogo CISA KEV y EPSS, y añada después la alcanzabilidad y el impacto en el negocio que salen del propio alcance.
¿Cuánto se tarda en pasar de la gestión de vulnerabilidades a CTEM?
Un ciclo con un alcance estrecho puede ejecutarse en unos 90 días, como se expone en el plan de 90 días. Extenderlo a todo el parque lleva más tiempo y se hace alcance por alcance.
Siguiente
Si la prueba de un ciclo salió mayoritariamente no, Cómo iniciar un programa CTEM en 90 días es el camino desde un escáner renombrado hasta un ciclo real. Las únicas métricas CTEM que la dirección leerá muestra de qué se puede informar una vez que la validación y la movilización producen evidencia, y la evaluación le dirá cuál de los cambios anteriores queda más lejos.