CVSS v3.1 vs v4.0: qué cambia y cómo puntuar bien

CVSS v4.0 (noviembre de 2023) no es un parche cosmético sobre v3.1: cambia cómo se modela el impacto, reorganiza los grupos de métricas y —lo más importante— insiste en algo que la gente llevaba años ignorando: la nota base no es el riesgo. Si vienes de v3.1, estos son los cambios que de verdad importan y los errores que se repiten al puntuar.

1. El impacto ahora mira a dos sistemas, no a un «scope»

En v3.1 el famoso Scope (S:U / S:C) era la métrica peor entendida: intentaba capturar «¿el fallo salta a otro componente?» con un único bit, y medio mundo lo marcaba mal. v4.0 lo elimina y lo sustituye por impacto explícito sobre dos sistemas separados:

• Sistema vulnerable: VC / VI / VA (confidencialidad, integridad, disponibilidad del propio componente afectado).
• Sistemas posteriores: SC / SI / SA (lo que hay más allá: otros equipos, la red, el navegador de la víctima…).

Un XSS, por ejemplo, casi no toca el servidor vulnerable pero pega de lleno en el sistema posterior (el navegador del usuario). Ahora eso se expresa sin acrobacias.

2. Complejidad (AC) y Requisitos del ataque (AT) se separan

En v3.1, AC:H mezclaba dos cosas distintas: «hay que vencer una mitigación» y «depende de una condición de carrera / posición MITM / configuración concreta». v4.0 las divide:

• AC — Attack Complexity: ¿el atacante tiene que derrotar activamente una defensa (ASLR, canarios, validación)?
• AT — Attack Requirements: ¿existen condiciones de despliegue o ejecución fuera de su control (ganar una carrera, estar en la ruta de red, una config no por defecto)?

3. User Interaction deja de ser un sí/no

v3.1 solo tenía «None / Required». v4.0 distingue None / Passive / Active: no es lo mismo que la víctima no haga nada, que abra un documento sin saberlo (pasiva), o que siga una secuencia concreta de pasos (activa). Afina el realismo del vector.

4. Temporal se convierte en «Threat» y adelgaza

El grupo Temporal de v3.1 tenía tres métricas; dos envejecieron mal (Remediation Level y Report Confidence). v4.0 se queda con una sola métrica de amenaza:

• E — Exploit Maturity: Attacked (se explota ya, o hay automatización), PoC (solo prueba de concepto), Unreported (sin explotación conocida). X = «no definido» y asume el peor caso, igual que la base.

5. Entorno: tu contexto, con «Safety» para OT/ICS

El grupo de entorno sigue teniendo los requisitos de C/I/A del negocio (¿cuánto te duele perder cada uno?) y las métricas base modificadas para tu despliegue concreto. La novedad: MSI y MSA admiten el valor Safety — pensado para entornos donde un fallo de integridad/disponibilidad puede afectar a vidas humanas (industrial, médico, automoción).

6. Suplementarias: contexto que NO cambia la nota

v4.0 añade un grupo Supplemental puramente informativo. No toca la puntuación; sirve para priorizar y para que el proveedor comunique matices:

• Safety, Automatable (¿se puede automatizar recon→explotación, estilo gusano?), Recovery, Value Density (recursos difusos vs concentrados), Response Effort y Provider Urgency (Clear/Green/Amber/Red).

7. Ya no hay fórmula que puedas hacer a mano

v3.1 tenía ecuaciones cerradas: con paciencia salía a lápiz. v4.0 puntúa por MacroVector (agrupa las combinaciones y interpola distancias contra una tabla de referencia). En la práctica: necesitas una calculadora; no hay ecuación que teclear.

El nombre del score depende de lo que incluyas

Y esto es lo que más se ignora. FIRST nomenclatura la nota según los grupos que aportes:

CVSS-B    solo Base           → severidad intrínseca
CVSS-BT   Base + Threat       → + madurez del exploit
CVSS-BE   Base + Environment  → + tu contexto
CVSS-BTE  todo                → la foto completa

Publicar el CVSS-B «pelado» (ese 9.8 del titular) y tratarlo como riesgo es el error de fondo: la base mide severidad intrínseca en el peor caso, no la probabilidad de que te toque a ti.

De la nota a la decisión

Puntuar bien es el primer paso, no el último. Una vez tienes un CVSS realista, para priorizar parches hace falta más: la probabilidad real de explotación (EPSS), si ya se explota en la práctica (KEV de CISA) y tu exposición. Lo desarrollo en «Qué CVE parchear primero».

Checklist para puntuar sin meter la pata

• ✅ ¿Impacto en el sistema vulnerable, en los posteriores, o en ambos? (adiós al bit de Scope)
• ✅ ¿El obstáculo es una defensa (AC) o una condición del entorno (AT)?
• ✅ User Interaction: None / Passive / Active, no sí/no
• ✅ ¿Estás publicando CVSS-B y llamándolo «riesgo»? No lo es
• ✅ Añade Threat y Entorno antes de decidir; X = peor caso
• ✅ Para priorizar de verdad: CVSS + EPSS + KEV + exposición

v4.0 no es más difícil, es más honesto: te obliga a decir qué estás midiendo. Y casi siempre, ese 9.8 del titular era una base sin contexto.

Sergio Belmonte Morales
Analista de Ciberseguridad · SOC · Especialista en Sentinel/KQL