CVSS ya no basta: priorizar vulnerabilidades exige saber qué toca el negocio
Un escáner marca severidad crítica, pero no sabe si ese sistema sostiene los ingresos o es una base de datos de pruebas. La priorización se ha vuelto un problema de asignación, no de parcheo.

Un investigador escaneaba la infraestructura de una empresa B2B de 300 empleados con presencia internacional cuando dio con una base de datos expuesta a internet y con autenticación débil. Severidad crítica, candidata evidente a ser lo primero que se parchea. Al inspeccionarla mejor, resultó ser un entorno de pruebas reseteable que la compañía usaba para evaluar candidatos en procesos de selección, no un sistema con datos de clientes. El episodio deja a la vista el agujero de fondo: un escáner calcula severidad, no coste de negocio.
La consecuencia práctica es que los equipos de seguridad se ahogan. Los programas absorben eventos de identidad, logs de firewall, alertas de endpoint, feeds de proveedores e inteligencia de amenazas, y generan mucho más material de análisis que hace unos años. Todo parece urgente. Con horas finitas, decidir dónde se interviene primero es la pregunta más importante que responde un responsable de seguridad cada día.
CVSS mide severidad, no exposición
El Common Vulnerability Scoring System sigue siendo un punto de partida útil. Sus métricas base clasifican una vulnerabilidad por vector de ataque, complejidad, privilegios necesarios e impacto sobre confidencialidad, integridad y disponibilidad. Pero están diseñadas para ser estables entre entornos, así que no pueden decir si el activo está expuesto a internet, si lo cubren controles compensatorios o si es central para el negocio. Tratar la puntuación base como un ticket automático de arreglo inmediato es el error. CVSS admite métricas de amenaza y ambientales, pero la gestión de riesgos sigue dependiendo de conocer el entorno con precisión y de aplicar ese contexto con criterio.
"La pieza que falta en cualquiera de estas herramientas es el anclaje en el negocio, entender qué importa de verdad", dice Jon Rose, fundador de IOmergent, firma de asesoría en seguridad de la información y gestión de riesgos.
Alcance, consecuencia y explotación real
Un marco de decisión sensato rebaja la urgencia de la nota y pregunta primero por la alcanzabilidad: si el atacante puede llegar de verdad al componente afectado o si está aislado detrás de controles de red. Después, por la consecuencia. Un fallo expuesto en un sistema de pruebas desechable es un problema real, pero no pesa lo mismo que una debilidad en la aplicación que procesa transacciones, guarda información sensible o sostiene el grueso de los ingresos.
Queda el tercer eje: si esa debilidad está atrayendo interés activo de atacantes. Que aparezca en el catálogo de vulnerabilidades explotadas conocidas de CISA obliga a mirarla con urgencia, porque hay evidencia de explotación en el mundo real. El Exploit Prediction Scoring System añade una señal hacia delante: la probabilidad estimada de que esa explotación se observe en los próximos 30 días. Ninguno de los dos sustituye a la decisión de negocio, pero separan el riesgo teórico del que exige atención ahora.
El reloj, además, corre más rápido. La automatización con IA abarata la construcción y el armamento de exploits, y la ventana entre lo que se sabe vulnerable y lo que ya se explota se estrecha. También importa la ruta de ataque: un fallo modesto que abre camino a cuentas privilegiadas o a un sistema de producción pasa al frente, mientras uno grave pero inalcanzable puede esperar. Ese juicio es el trabajo, y no se delega en una puntuación.


