VPR, SSVC y el Futuro de la Priorización de Vulnerabilidades

Más allá de CVSS: por qué la severidad no basta

Durante casi dos décadas, CVSS (Common Vulnerability Scoring System) ha sido el lenguaje universal para medir la gravedad de las vulnerabilidades. Un CVSS 9.8 suena alarmante. Un 4.3, manejable. El problema es que esta escala de severidad no responde a la pregunta que los equipos de seguridad realmente necesitan contestar: ¿qué parcheo primero con los recursos que tengo?

Los números lo explican mejor que cualquier argumento teórico. CVSS clasifica aproximadamente el 60% de las vulnerabilidades publicadas como altas o críticas (score 7.0 o superior). Si tu organización tiene 10.000 CVEs pendientes, CVSS te dice que 6.000 son urgentes. Eso no es priorización. Es parálisis.

La industria lleva años desarrollando alternativas que incorporan lo que CVSS ignora: contexto de amenazas, probabilidad real de explotación, madurez de exploits y criticidad del activo afectado. Los dos frameworks más relevantes son VPR de Tenable y SSVC de CISA/Carnegie Mellon. Junto con EPSS de FIRST.org, forman un ecosistema de priorización que supera con creces la utilidad de CVSS como herramienta de decisión.

Tenable VPR: inteligencia de amenazas en tiempo real

Qué es VPR

Vulnerability Priority Rating (VPR) es un sistema propietario desarrollado por Tenable que reemplaza la severidad estática de CVSS con un score dinámico que incorpora inteligencia de amenazas actualizada diariamente. VPR genera un score de 0.1 a 10.0, pero la distribución es radicalmente diferente a la de CVSS.

Cuando Tenable lanzó VPR en 2019, solo clasificó el 3% de las vulnerabilidades como altas o críticas. En las actualizaciones más recientes del modelo, esa cifra ha bajado al 1,6%. Compárese con el 60% de CVSS. La diferencia entre priorizar 6.000 CVEs y priorizar 160 es la diferencia entre un equipo saturado y un equipo que puede actuar con precisión.

Cómo funciona

VPR combina dos componentes principales:

Impacto técnico. Similar a CVSS, mide las consecuencias de la explotación sobre confidencialidad, integridad y disponibilidad del sistema afectado.

Componente de amenaza. Aquí está la innovación. Tenable analiza en tiempo real:

1. Madurez del exploit. ¿Existe un exploit público? ¿Está en Metasploit? ¿Es un PoC conceptual o un exploit weaponizado listo para usar? VPR distingue entre niveles de madurez: conceptual, PoC, funcional e integrado en herramientas de ataque.
2. Actividad de amenazas. Datos de sensores de red, honeypots, foros underground y dark web que indican si los atacantes están utilizando o discutiendo la vulnerabilidad.
3. Edad y tendencia. Las vulnerabilidades recientes con exploits funcionales tienen mayor score. Las antiguas sin actividad reciente bajan.
4. Vectores de ataque. Si la explotación es remota, sin autenticación y automatizable, el score sube significativamente.

Actualización diaria

A diferencia de CVSS, que es estático una vez asignado, VPR se recalcula cada día. Si hoy aparece un módulo de Metasploit para una CVE que ayer tenía VPR bajo, el score sube al día siguiente. Si una CVE deja de explotarse activamente durante meses, el score baja. Esta dinámica refleja la realidad de que el riesgo de una vulnerabilidad no es constante en el tiempo.

Limitaciones de VPR

VPR es un sistema propietario integrado en los productos de Tenable (Nessus, Tenable.io, Tenable.sc). No existe una API pública gratuita como en EPSS. Las organizaciones que no usan productos Tenable no pueden acceder a los scores VPR directamente, aunque los conceptos subyacentes pueden replicarse combinando EPSS con fuentes propias de threat intelligence.

CISA SSVC: decisiones, no números

Qué es SSVC

Stakeholder-Specific Vulnerability Categorization (SSVC) es un framework desarrollado por Carnegie Mellon University (SEI) en colaboración con CISA. A diferencia de CVSS, VPR y EPSS, SSVC no produce un score numérico. Produce una decisión explícita: qué hacer con la vulnerabilidad.

SSVC fue creado en 2019 y adoptado por CISA en 2020 para gestionar vulnerabilidades en el gobierno de Estados Unidos, infraestructuras críticas y gobiernos estatales y locales. Desde 2024, CISA enriquece activamente registros CVE con decisiones SSVC a través de su proyecto Vulnrichment.

El árbol de decisión

SSVC evalúa cinco criterios en secuencia para llegar a una de cuatro decisiones posibles:

Criterio 1: Estado de explotación (Exploitation)

• Active: Explotación confirmada en el mundo real.
• PoC: Existe código de prueba de concepto público.
• None: No se conoce exploit ni PoC.

Criterio 2: Automatizabilidad (Automatable)

• Yes: La explotación se puede automatizar (ej: escaneo masivo por Internet, sin interacción humana requerida).
• No: Requiere interacción manual significativa o condiciones difíciles de reproducir.

Criterio 3: Impacto técnico (Technical Impact)

• Total: El atacante obtiene control completo del sistema (ejecución de código, acceso root).
• Partial: El atacante obtiene acceso limitado (lectura de información, denegación de servicio).

Criterio 4: Prevalencia de misión (Mission Prevalence)

• Essential: El activo afectado es esencial para la misión de la organización.
• Support: El activo soporta funciones de la organización pero no es crítico.
• Minimal: Impacto mínimo en las operaciones.

Criterio 5: Impacto en bienestar público (Public Well-Being Impact)

• Significant: La explotación podría afectar la salud, seguridad o bienestar de la población.
• Minimal: Sin impacto directo en el bienestar público.

Las cuatro decisiones

El resultado del árbol no es un número. Es una de estas acciones:

Decisión	Significado	Plazo de acción
Track	Monitorizar, no se requiere acción inmediata	Sin plazo fijo
Track*	Monitorizar con atención, podría escalar	Revisión periódica
Attend	Remediar antes del ciclo normal de parcheo	Días a semanas
Act	Remediar inmediatamente	Horas a días

Ejemplo práctico de SSVC

Imaginemos una CVE de inyección SQL en un servidor web expuesto a Internet:

1. Exploitation: PoC disponible en GitHub.
2. Automatable: Sí, un script puede escanear y explotar servidores vulnerables.
3. Technical Impact: Total (el atacante puede leer y modificar la base de datos completa).
4. Mission Prevalence: Essential (es el servidor de la aplicación principal de la empresa).
5. Public Well-Being: Minimal (empresa privada sin impacto en infraestructura crítica).

Resultado SSVC: Act. Remediar inmediatamente.

Ahora imaginemos la misma CVE, pero el servidor afectado es un entorno de desarrollo interno sin datos reales:

1. Exploitation: PoC disponible.
2. Automatable: No (solo accesible desde la red interna).
3. Technical Impact: Total.
4. Mission Prevalence: Minimal (entorno de desarrollo).
5. Public Well-Being: Minimal.

Resultado SSVC: Track*. Monitorizar con atención, incluir en el ciclo regular.

La misma CVE, dos decisiones diferentes. Eso es priorización contextual.

Comparación de todos los frameworks

Tabla comparativa

Criterio	CVSS	EPSS	KEV	VPR	SSVC
Mide	Severidad técnica	Prob. explotación 30d	Explotación confirmada	Severidad + amenaza	Decisión contextual
Rango	0.0 a 10.0	0.0 a 1.0	Sí/No (binario)	0.1 a 10.0	Track/Track*/Attend/Act
Actualización	Estático	Diario	Cuando se confirma	Diario	Según evaluación
Coste	Gratuito	Gratuito	Gratuito	Propietario (Tenable)	Gratuito
Contexto org.	No	No	No	Parcial	Sí (mission, well-being)
Threat intel	No	Sí (ML)	Sí (confirmación)	Sí (feeds propios)	Parcial (exploitation)
Quién lo usa	Universal	Cualquiera	Gobierno US, empresas	Clientes Tenable	Gobierno US, empresas

Qué responde cada framework

• CVSS: "¿Qué tan grave es esta vulnerabilidad técnicamente?" (severidad).
• EPSS: "¿Qué probabilidad hay de que se explote en 30 días?" (probabilidad).
• KEV: "¿Se está explotando ya?" (confirmación binaria).
• VPR: "¿Qué tan urgente es parchearla considerando la amenaza actual?" (urgencia).
• SSVC: "¿Qué debemos hacer al respecto dado nuestro contexto?" (decisión).

Construyendo tu propio framework de priorización

No hace falta elegir un solo sistema. Las organizaciones más maduras combinan varios para crear un pipeline de priorización propio.

El stack ideal

Capa 1: CISA KEV → ¿Está en el catálogo?
  └── Sí → PRIORIDAD MÁXIMA, remediar inmediatamente
  └── No → Continuar a Capa 2

Capa 2: EPSS → ¿Score >= 0.10?
  └── Sí → Prioridad alta, evaluar contexto
  └── No → Continuar a Capa 3

Capa 3: CVSS → ¿Score >= 9.0?
  └── Sí → Prioridad media-alta (severidad alta aunque sin explotación conocida)
  └── No → Continuar a Capa 4

Capa 4: Contexto de activos → ¿Activo crítico expuesto a Internet?
  └── Sí → Subir una categoría de prioridad
  └── No → Mantener prioridad actual

Capa 5: Datos sensibles → ¿El activo procesa PII, datos financieros o salud?
  └── Sí → Subir una categoría de prioridad
  └── No → Prioridad final

Ejemplo con 100 CVEs

Para demostrar el impacto de cada framework, simulemos la clasificación de 100 CVEs:

Framework	Críticas/Urgentes	Altas	Medias	Bajas
CVSS	15	45	30	10
VPR	2	5	25	68
EPSS >= 0.10	4	n/a	n/a	96
KEV	3 (en catálogo)	n/a	n/a	97
SSVC (Act)	5	n/a	n/a	n/a
Stack combinado	6	8	20	66

CVSS por sí solo dice que 60 de las 100 CVEs son altas o críticas. El stack combinado identifica 6 como realmente urgentes. Esa diferencia de 54 CVEs representa cientos de horas de trabajo que se pueden redirigir a lo que importa.

SSVC en la práctica: CISA Vulnrichment

Desde 2024, CISA automatiza parcialmente las decisiones SSVC a través de su proyecto Vulnrichment. Este proyecto enriquece los registros CVE en el programa CVE con datos adicionales, incluyendo decisiones SSVC automatizadas para vulnerabilidades relevantes.

Vulnrichment evalúa los criterios de explotación y automatizabilidad de forma automática, utilizando datos de fuentes como CISA KEV, Exploit-DB y bases de datos de exploits. Los criterios de misión e impacto público se aplican desde la perspectiva del gobierno de Estados Unidos, pero las organizaciones pueden sustituirlos por sus propios criterios.

CISA también proporciona una calculadora SSVC pública en https://www.cisa.gov/ssvc-calculator que permite a cualquier organización evaluar una vulnerabilidad según los cinco criterios del árbol de decisión.

El futuro: convergencia y automatización

La tendencia es clara: la industria se mueve hacia la priorización automatizada y contextual. Los proveedores de escáneres de vulnerabilidades ya integran múltiples señales (CVSS, EPSS, KEV, feeds propios) para generar recomendaciones de priorización combinadas.

Lo que viene

1. EPSS v4 y más allá. FIRST.org continúa mejorando el modelo con más fuentes de datos y mejor calibración.
2. SSVC automatizado. La automatización completa del árbol de decisión SSVC, incluyendo integración con inventarios de activos para evaluar misión e impacto.
3. Priorización por contexto de cadena de ataque. No solo evaluar CVEs individuales, sino su combinación en cadenas de ataque (si el atacante puede encadenar tres CVEs de severidad media para lograr RCE, la prioridad debe subir).
4. IA para predicción personalizada. Modelos que predigan explotación no solo a nivel global, sino específicamente contra tu sector, geografía y stack tecnológico.

Recomendaciones por madurez organizacional

Organizaciones en nivel inicial

Si tu equipo de seguridad no tiene procesos formales de gestión de vulnerabilidades, empieza por lo básico:

1. Integra CISA KEV y EPSS en tu escáner.
2. Parchea todo lo que esté en KEV.
3. Para el resto, usa EPSS >= 0.10 como umbral de acción inmediata.

Organizaciones en nivel intermedio

Si ya tienes procesos de parcheo establecidos:

1. Implementa la matriz CVSS x EPSS descrita en el artículo anterior sobre EPSS.
2. Evalúa SSVC para tus activos más críticos.
3. Incorpora contexto de activos (criticidad, exposición, datos que procesan).

Organizaciones en nivel avanzado

Si tienes un programa de vulnerability management maduro:

1. Implementa SSVC completo con criterios personalizados para tu organización.
2. Automatiza la evaluación combinando datos de CMDB, EPSS, KEV y threat intelligence propia.
3. Mide la efectividad de tu priorización: ¿cuántas de las CVEs que no priorizaste terminaron siendo explotadas? (métrica de falsos negativos).
4. Evalúa VPR o construye un score propietario que combine las señales relevantes para tu contexto.

Conclusión: la priorización es un problema de decisión, no de puntuación

El error más común en gestión de vulnerabilidades es tratar la priorización como un problema numérico. "Parchear todo lo que tenga CVSS mayor a 7." Eso no es una estrategia. Es una confesión de que no tenemos la información necesaria para tomar decisiones informadas.

Los frameworks modernos (VPR, SSVC, EPSS) reconocen que la priorización efectiva requiere múltiples dimensiones de información: severidad técnica, probabilidad de explotación, confirmación de explotación activa, contexto del activo afectado e impacto en la misión de la organización. Ningún número individual puede capturar toda esa complejidad.

La pregunta no es "¿cuál es el mejor framework?" sino "¿qué combinación de señales necesito para tomar buenas decisiones de parcheo con los recursos que tengo?" La respuesta varía según la organización, pero la dirección es universal: más contexto, menos ruido, mejores decisiones.