¿Por qué tu backlog de vulnerabilidades críticas no suele bajar, aunque el equipo trabaje bien?

Revisa tu último reporte mensual. Probablemente muestre más activos escaneados, más hallazgos detectados y más cobertura que el trimestre pasado. Y abajo, casi siempre, el mismo backlog de críticas que tenías hace seis meses.

Esa foto convive con una pregunta que rara vez tiene respuesta corta: ¿tu organización está más expuesta o menos expuesta que hace medio año?

Si la respuesta tarda en llegar, no es un problema de datos. Tampoco es que tu equipo esté haciendo mal el trabajo. Es un problema de modelo. Y le pasa incluso a equipos maduros con buenas herramientas.

El problema nunca fue la visibilidad 

Durante la última década, la industria resolvió bien un problema real: ver. Hoy ves la nube, el on-premise, las aplicaciones, los activos que nadie registró y hasta los que alguien levantó el viernes a las seis. El cuello de botella dejó de estar en la detección y se movió, casi sin que nos diéramos cuenta, a la capacidad de convertir esos hallazgos en remediación priorizada y medible.

Piénsalo en términos de caudal. Cada semana entran miles de hallazgos nuevos a tu operación. Del otro lado, la capacidad de remediar —ventanas de mantenimiento, equipos de infraestructura, aprobaciones de cambio, dueños de aplicación que también tienen su propio roadmap— es prácticamente la misma que tenías hace dos años.

Cuando la entrada crece y la salida no, el resultado no es un fallo del equipo. Es aritmética. El backlog se acumula, las críticas envejecen y la superficie de ataque se ensancha mientras todos trabajan más que nunca.

Por eso la frase que mejor describe el momento actual no es "nos falta visibilidad", sino esta otra: no falta información, falta capacidad para convertirla en acciones efectivas.

Lo incómodo de ese diagnóstico es que no se ve. Un modelo que llegó a su límite no colapsa: sigue entregando reportes puntuales, escaneos al día y cumplimiento en verde. Por eso no lo vas a detectar en un tablero. Lo vas a detectar en las conversaciones que tienes cada mes.

8 señales que indican que tu modelo actual de gestión de vulnerabilidades necesita evolucionar

Lee estas ocho frases y cuenta cuántas te resultan familiares:

• Cada mes reaparecen las mismas vulnerabilidades.
• El backlog crece de forma constante, hagas lo que hagas.
• Hay más reportes que acciones.
• Los indicadores muestran cantidad de hallazgos, pero ninguno muestra reducción de riesgo.
• El equipo trabaja más y logra menos.
• Infraestructura percibe la gestión de vulnerabilidades como una carga administrativa.
• La priorización sigue dependiendo únicamente del CVSS.
• No existe una visión centralizada del riesgo: cada herramienta cuenta su propia historia.

Si marcaste cuatro o más, lo que tienes no es un problema de ejecución. Es un modelo que llegó a su límite.

Si ¿Marcaste cuatro o más? Revisemos tu modelo actual con un especialista. Un diagnóstico para conocer tu punto de partida, sin demo. Agenda tu sesión aquí

Y fíjate en la séptima. Esa es, en la mayoría de los casos, la que arrastra a las otras siete.

¿Por qué el CVSS ya no alcanza para priorizar?  

Porque el CVSS mide la criticidad técnica de una vulnerabilidad de forma aislada: no sabe si existe explotación activa, ni qué tan expuesto está el activo, ni qué proceso de negocio depende de él. Por eso dos vulnerabilidades con el mismo puntaje pueden representar riesgos completamente distintos.

Piensa en dos hallazgos, ambos 9.8. El primero vive en un servidor interno, segmentado, sin exploit conocido y sin exposición a internet. El segundo está en la aplicación que factura, publicada hacia afuera, con exploit circulando desde hace una semana.

Para tu tablero son idénticos. Para tu organización, uno puede esperar y el otro no debería haber esperado nunca.

Ahora multiplica esa decisión por veinte mil hallazgos y tienes el retrato exacto de por qué un equipo competente puede pasar el trimestre entero remediando sin mover la aguja del riesgo. No es que prioricen mal. Es que están priorizando con una sola variable en un problema que tiene cinco.

Las cinco variables que sí definen el riesgo real 

1. Explotabilidad: ¿existe exploit disponible y en uso?
2. Valor del activo: ¿qué sostiene ese sistema?
3. Exposición: ¿es alcanzable desde afuera o está detrás de tres capas?
4. Inteligencia de amenazas: ¿alguien la está usando hoy contra tu sector?
5. Contexto del negocio: ¿qué pasa si ese servicio se cae mañana a las nueve?

Cruzar esas cinco variables una vez es un ejercicio. Cruzarlas cada semana, sobre una superficie que cambia todos los días, ya no cabe en una hoja de cálculo ni en la agenda de nadie. Y el reloj tampoco ayuda: los atacantes empiezan a explotar vulnerabilidades conocidas en días u horas tras la divulgación, mientras muchas organizaciones tardan semanas o meses en remediarlas. La ventana no la define tu calendario de parcheo. La define el adversario.

Por eso el salto que están dando los equipos que sí reducen exposición no es tecnológico. Es de unidad de trabajo: dejan de administrar una lista y empiezan a operar un ciclo.

¿Qué cambia en la operación cuando pasas a un modelo CTEM? 

Las siglas ya las conoces. Lo que rara vez se discute es qué cambia el lunes por la mañana cuando CTEM deja de ser un marco de referencia y se vuelve la forma en que tu equipo trabaja.

Cambia, sobre todo, que el trabajo deja de organizarse por campañas —escaneo, reporte, remediación, repetir— y pasa a organizarse como ciclo continuo: descubrimiento, priorización por riesgo, validación, orquestación de la remediación, seguimiento, medición y mejora. Siete etapas que no terminan nunca, porque la superficie tampoco lo hace.

La etapa que más cambia la vida del equipo es la tercera. Validar significa comprobar si eso que el escáner marcó como crítico es realmente explotable en tu arquitectura, con tus controles y tus segmentaciones puestas. Y es la que más backlog elimina sin que nadie toque un parche: no porque ignore hallazgos, sino porque deja de tratar como urgente lo que en tu entorno no lo es. Si alguna vez sentiste que tu equipo se agota corriendo detrás de hallazgos que nunca representaron una amenaza real, ese es exactamente el problema que resuelve.

Ahora bien, un ciclo continuo no se sostiene solo. Necesita alguien que lo opere todos los días. Y ahí es donde suele aparecer la pregunta.

¿En qué se diferencia un ROC de un SOC?

Un SOC trabaja sobre alertas. Las herramientas de detección generan un flujo constante de eventos y el trabajo del analista es investigarlos, descartar el ruido, confirmar cuáles corresponden a actividad maliciosa real y responder a los que quedan. Un ROC (Risk Operations Center) trabaja sobre la exposición: centraliza la superficie digital, prioriza el riesgo real, coordina la remediación y mide su impacto, antes de que nada de eso llegue a generar una alerta. Son funciones complementarias, no sustitutas.

La diferencia práctica es de reloj. El SOC vive en el presente y sus métricas son de triage y respuesta: cuánto tarda una alerta en convertirse en incidente confirmado y cuánto tarda ese incidente en contenerse. El ROC vive antes de todo eso y su métrica es cuánta superficie dejó de existir. Uno mide qué tan rápido reaccionas; el otro, qué tan poco tienes que reaccionar.

Y hay una diferencia de alcance que suele pasarse por alto: el SOC trabaja sobre telemetría y alertas de seguridad, mientras que el ROC correlaciona fuentes que hoy viven separadas y no se hablan entre sí —VM, ASM, EASM, CSPM, AppSec, Threat Intelligence—. Correlacionarlas es justamente lo que permite que las cinco variables de priorización dejen de ser una intención y se vuelvan un criterio ejecutable.

Sobre esa base, el ROC automatiza el trabajo repetitivo, coordina la remediación con infraestructura y aplicaciones, mide el efecto de cada acción y traduce todo a indicadores que el comité entiende. Que es, casualmente, donde estaba el problema al inicio de este artículo.

¿Qué cambia en los indicadores cuando operas bajo CTEM?

Porque si solo pudieras cambiar una cosa este año, deberías cambiar lo que mides. Los indicadores tradicionales miden actividad; los de un ROC miden resultado. 

Parece un detalle de gobierno y en realidad es un cambio de conversación. Con la columna izquierda justificas esfuerzo. Con la derecha justificas presupuesto. Cualquiera que haya presentado ante un comité sabe cuál de las dos conversaciones termina mejor. 

¿Cómo empezar sin rehacer todo desde cero?

La buena noticia es que nada de esto exige tirar a la basura lo que ya construiste. Las plataformas que tienes siguen siendo la fuente de datos; lo que falta es la operación encima: metodología CTEM, correlación de las tecnologías que ya usas, priorización por riesgo de negocio, gobierno del ciclo completo y especialistas que sostengan el ritmo cuando tu equipo esté apagando otra cosa.

Dicho de otro modo: no te falta información y probablemente tampoco te falten herramientas. Te falta una operación que convierta lo uno en lo otro.

Porque la realidad es que el reto ya no se basa en identificar vulnerabilidades. El desafío real está en reducir continuamente la exposición.

Así que vale la pena volver a la pregunta del principio, esta vez sin anestesia: ¿tu organización está reduciendo el riesgo o generando más reportes?