CVE vs CVSS: ¿cuál es la diferencia?
CVE identifica qué es una vulnerabilidad. CVSS puntúa cuán grave es. Dos sistemas complementarios, gestionados por dos organizaciones distintas, descifrados pieza a pieza con un vector resuelto.
Abre cualquier aviso de seguridad de un proveedor y normalmente verás dos cosas unidas: un código como CVE-2024-12345 y un número como 9.8 CRÍTICO. Es fácil tratarlos como un solo dato, pero proceden de dos organizaciones distintas, responden a dos preguntas distintas, y se confunden constantemente. CVE (Common Vulnerabilities and Exposures) es un sistema de nomenclatura: identifica qué es una vulnerabilidad concreta, para que todo el mundo pueda hablar del mismo fallo sin ambigüedad. CVSS (Common Vulnerability Scoring System) es una escala de gravedad: mide cuán grave es esa vulnerabilidad en una escala de 0 a 10. Uno nombra el problema. El otro lo puntúa. Este artículo explica ambos en detalle, y descifra un vector CVSS real pieza a pieza para que la puntuación deje de ser una caja negra.
Qué es realmente CVE
CVE es un catálogo de vulnerabilidades públicamente conocidas, mantenido por MITRE Corporation con financiación de la Agencia de Ciberseguridad e Infraestructura de EE. UU. (CISA). Su función es, ante todo, la desambiguación: antes de que existiera CVE, distintos proveedores, escáneres e investigadores usaban habitualmente sus propios nombres internos para el mismo fallo subyacente, lo que dificultaba saber si dos avisos describían un mismo bug o dos distintos. CVE soluciona esto asignando a cada vulnerabilidad que cumple los requisitos un identificador único y permanente con el formato:
CVE-2024-12345
^^^^ ^^^^^
año número de secuencia
El año refleja cuándo se asignó el ID, no necesariamente cuándo se descubrió, divulgó o corrigió la vulnerabilidad: un ID reservado en diciembre puede divulgarse públicamente la primavera siguiente y seguir llevando el año anterior. MITRE no revisa personalmente cada envío; acredita a organizaciones llamadas CVE Numbering Authorities (CNA) —grandes proveedores, firmas de investigación de seguridad, plataformas de bug bounty y centros de coordinación— para que asignen IDs a las vulnerabilidades dentro de su propio ámbito. Un registro CVE típico contiene:
| Campo | Qué contiene |
|---|---|
| ID de CVE | El identificador único, p. ej. CVE-2024-12345 |
| Descripción | Un resumen en lenguaje llano de la vulnerabilidad y el componente afectado |
| Productos afectados | Normalmente referenciados mediante cadenas CPE (Common Platform Enumeration) que identifican combinaciones exactas de proveedor/producto/versión |
| Referencias | Enlaces a avisos del proveedor, parches y análisis de investigadores |
Fíjate en lo que falta: una puntuación de gravedad. Un registro CVE en bruto solo dice que existe un fallo y lo describe; por sí solo no te dice cuán peligroso es ese fallo. Esa tarea le corresponde por completo a CVSS.
Qué es realmente CVSS
CVSS lo mantiene FIRST.org (el Forum of Incident Response and Security Teams), una organización sin ánimo de lucro independiente: una organización distinta de MITRE, gestionada con un propósito distinto. Donde CVE responde a «qué es este fallo», CVSS responde a «cuán grave es», expresado como un único número de 0.0 a 10.0. Ese número no se asigna por intuición; se calcula a partir de un conjunto de métricas estandarizadas que describen cómo se puede explotar una vulnerabilidad y qué ocurre si se explota, cada una codificada en un vector compacto que cualquiera puede leer para ver exactamente cómo se construyó la puntuación.
CVSS ha pasado por varias revisiones importantes: la versión 2 en 2007, la versión 3.0 y su refinamiento 3.1 en 2015 y 2019, y la versión 4.0, publicada por FIRST.org en 2023. CVSS 3.1 sigue siendo la versión que más vas a encontrar hoy en avisos de proveedores y bases de datos de vulnerabilidades, así que es la que merece la pena entender en profundidad primero.
Las métricas de la puntuación base de CVSS 3.1
La puntuación base se construye a partir de ocho métricas, divididas en dos grupos: métricas de explotabilidad, que describen cómo un atacante alcanza y explota el fallo, y métricas de impacto, que describen qué le ocurre al sistema una vez que lo hace.
| Métrica | Abreviatura | Valores posibles | Qué mide |
|---|---|---|---|
| Vector de ataque | AV | Red (N), Adyacente (A), Local (L), Físico (P) | Desde cuán lejos se puede alcanzar la vulnerabilidad — Red es lo más grave, alcanzable por internet |
| Complejidad del ataque | AC | Baja (L), Alta (H) | Si la explotación requiere condiciones especiales o preparación fuera del control del atacante |
| Privilegios requeridos | PR | Ninguno (N), Bajo (L), Alto (H) | Qué nivel de acceso necesita el atacante antes de intentar la explotación |
| Interacción del usuario | UI | Ninguna (N), Requerida (R) | Si la víctima tiene que hacer algo —hacer clic en un enlace, abrir un fichero— para que el exploit funcione |
| Alcance (Scope) | S | Sin cambios (U), Modificado (C) | Si explotar el fallo puede afectar a recursos más allá de la autoridad de seguridad propia del componente vulnerable |
| Impacto en confidencialidad | C | Ninguno (N), Bajo (L), Alto (H) | Cuánta divulgación de datos no autorizada resulta de una explotación exitosa |
| Impacto en integridad | I | Ninguno (N), Bajo (L), Alto (H) | Cuánta modificación de datos no autorizada resulta de una explotación exitosa |
| Impacto en disponibilidad | A | Ninguno (N), Bajo (L), Alto (H) | Cuánta interrupción de la disponibilidad del sistema resulta de una explotación exitosa |
El valor elegido para cada métrica alimenta una fórmula definida y publicada en la especificación CVSS, que produce la puntuación base final de 0.0–10.0. Nunca tienes que ejecutar esa fórmula a mano —cada escáner, cada aviso y la calculadora del NVD (la National Vulnerability Database del NIST) lo hacen por ti—, pero entender qué significa cada letra convierte un número opaco en un resumen técnico legible.
Descifrando un vector real
Un vector CVSS empaqueta las ocho métricas en una sola línea, en un orden fijo, con el prefijo de la versión de CVSS. Aquí tienes un ejemplo representativo del tipo de fallo que suele recibir una calificación Crítica: una vulnerabilidad explotable remotamente y sin autenticación, con impacto total:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Leído de izquierda a derecha, pieza a pieza:
AV:N— Vector de ataque: Red. Explotable remotamente por una conexión de red, sin necesidad de acceso físico o local.AC:L— Complejidad del ataque: Baja. No se requieren condiciones especiales ni sincronización; un exploit fiable funciona de forma consistente.PR:N— Privilegios requeridos: Ninguno. El atacante no necesita autenticación previa ni acceso a ninguna cuenta.UI:N— Interacción del usuario: Ninguna. La víctima no tiene que hacer clic, abrir nada ni realizar ninguna acción para que el exploit tenga éxito.S:U— Alcance: Sin cambios. El impacto se mantiene dentro de la autoridad de seguridad del propio componente vulnerable.C:H— Impacto en confidencialidad: Alto. Un atacante que triunfe puede leer datos a los que no debería tener acceso.I:H— Impacto en integridad: Alto. Un atacante que triunfe puede modificar datos o el estado del sistema que no debería poder tocar.A:H— Impacto en disponibilidad: Alto. Un atacante que triunfe puede interrumpir o tumbar por completo el sistema afectado.
Cada métrica de ese vector apunta hacia la máxima gravedad: alcanzable por cualquiera en la red, sin necesidad de inicio de sesión, sin interacción del usuario, sin condiciones especiales, y compromiso completo de la confidencialidad, la integridad y la disponibilidad. Pasado por la fórmula de CVSS 3.1, un vector como este aterriza en 9.8, situándolo en la banda Crítica. Cambia una sola métrica —por ejemplo, PR:N por PR:H, exigiendo que el atacante ya tenga privilegios altos— y la puntuación baja de forma sustancial, porque el conjunto de gente que realmente podría explotarlo se reduce drásticamente. Ese es todo el sentido del vector: la puntuación queda totalmente explicada por sus entradas, no se afirma de la nada.
Leer la escala de gravedad
La especificación de CVSS también define una escala cualitativa para poder hablar de las puntuaciones sin memorizar números exactos:
| Rango de puntuación | Calificación cualitativa |
|---|---|
| 0.0 | Ninguna |
| 0.1 – 3.9 | Baja |
| 4.0 – 6.9 | Media |
| 7.0 – 8.9 | Alta |
| 9.0 – 10.0 | Crítica |
Más allá de la puntuación base, CVSS 3.1 también define métricas temporales opcionales (que ajustan cosas como si existe públicamente código de exploit funcional o si ya hay un parche oficial) y métricas de entorno (que permiten a una organización reponderar la puntuación según lo crítico que sea realmente el activo afectado en su propio entorno). En la práctica, la puntuación base es la que se publica en avisos y bases de datos; la puntuación temporal y de entorno la aplica localmente cada organización que está priorizando la remediación.
CVSS 4.0: qué cambió
FIRST.org publicó CVSS 4.0 en 2023 para abordar varias críticas de larga data a la versión 3.1. La filosofía central de puntuación de 0 a 10 se mantiene, pero el conjunto de métricas se refinó: una nueva métrica de Requisitos de Ataque (AT) separa las condiciones que existen independientemente de los privilegios o la interacción del usuario, la confusa métrica Scope se sustituye por métricas de impacto más claras —Sistema Vulnerable y Sistema Subsiguiente— que describen el radio de impacto con más precisión, y ahora las puntuaciones se etiquetan explícitamente según qué grupos de métricas se usaron para calcularlas (CVSS-B para solo base, CVSS-BE para base más entorno, y así sucesivamente), lo que deja claro de un vistazo cuán completa es realmente una puntuación dada. La adopción ha sido gradual —CVSS 3.1 sigue siendo la versión que verás en la gran mayoría de avisos publicados hoy, pero las puntuaciones de 4.0 son cada vez más comunes en las divulgaciones más recientes.
Consultar los datos de CVE y CVSS por tu cuenta
Ambos catálogos son gratuitos y públicos, y consultarlos directamente suele ser más rápido y fiable que fiarse de un resumen de segunda mano. CVE.org es la fuente autoritativa para el propio registro CVE: busca por ID o palabra clave para ver la descripción canónica y qué CNA lo asignó. La National Vulnerability Database (NVD) del NIST es donde la mayoría de la gente va en realidad para obtener el panorama completo, porque añade puntuaciones CVSS, productos afectados emparejados por CPE y clasificaciones de debilidad CWE sobre el registro CVE base.
El NVD también expone una API JSON pública, así que el registro completo de un CVE —incluido su vector CVSS exacto— se puede obtener directamente desde la línea de comandos en lugar de leerlo en una página web:
# Buscar un CVE conocido y extraer su vector CVSS 3.1 publicado
$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228" \
| jq -r '.vulnerabilities[0].cve.metrics.cvssMetricV31[0].cvssData.vectorString'
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Ese es el vector real y publicado del NVD para CVE-2021-44228 —Log4Shell, el fallo crítico de ejecución remota de código en la ampliamente usada librería de logging Apache Log4j, divulgado en diciembre de 2021. Coincide con el ejemplo resuelto de arriba casi métrica por métrica, con una diferencia instructiva: S:C, Scope Modificado (Changed), en lugar de S:U. Como Log4j es un componente de logging incrustado dentro de incontables otras aplicaciones, explotarlo con éxito podía permitir a un atacante ejecutar código en el contexto de toda la aplicación anfitriona: un impacto que llega más allá de la autoridad de seguridad propia del componente vulnerable, que es exactamente la condición que la métrica Scope existe para capturar. La puntuación base general sigue aterrizando en 10.0, el máximo posible, y Crítica.
Cómo funcionan juntos CVE y CVSS en la práctica
La relación es complementaria, no competitiva, y entender eso resuelve la mayor parte de la confusión: CVE te da un nombre estable al que hacer referencia en avisos de proveedores, salidas de escáner, notas de parches y coberturas informativas, de modo que todos están discutiendo sin ambigüedad el mismo fallo. CVSS le da a ese fallo con nombre una puntuación de gravedad comparable, así que un equipo que se enfrenta a docenas o cientos de CVE abiertos tiene un punto de partida objetivo y reproducible para el triaje, en lugar de adivinar cuáles importan más. El NVD es donde estos dos sistemas se encuentran de forma más visible: la National Vulnerability Database del NIST ingiere registros CVE de MITRE y los enriquece con puntuaciones CVSS, datos de productos afectados por CPE y otro contexto, lo que la convierte en la fuente más citada para «la puntuación CVSS de un CVE», aunque CVE y CVSS en sí mismos procedan de organizaciones totalmente distintas.
Aun así, una puntuación base de CVSS por sí sola no es toda la historia de la priorización. Mide la gravedad teórica asumiendo que la explotación ocurre, pero no dice nada sobre si alguien está realmente explotando un fallo concreto en este momento. Por eso la gestión de vulnerabilidades madura combina CVSS con señales del mundo real —sobre todo el catálogo Known Exploited Vulnerabilities (KEV) de CISA, una lista pública de CVE confirmados bajo explotación activa—, junto con la exposición del activo concreto afectado. Un fallo calificado como Crítico en un sistema interno aislado (air-gapped) puede esperar razonablemente detrás de un fallo calificado como Medio en un servidor expuesto a internet que el KEV confirma que está siendo atacado activamente.
En resumen
CVE y CVSS resuelven problemas distintos por razones distintas. CVE, gestionado por MITRE, le da a cada vulnerabilidad públicamente conocida un nombre único e inequívoco con el formato CVE-AAAA-NNNNN. CVSS, gestionado por FIRST.org, puntúa cuán grave es esa vulnerabilidad con nombre en una escala transparente de 0 a 10 construida a partir de un vector descifrable que cubre cómo se explota y qué daña. Ninguno sustituye al otro, y ninguno debería leerse en solitario: un ID de CVE te dice con qué estás lidiando, una puntuación CVSS te dice más o menos cuán grave es en abstracto, y los datos de explotación del mundo real te dicen si realmente se está usando contra sistemas como el tuyo ahora mismo. La priorización ocurre en la intersección de los tres.
