CVSS: Cómo Se Puntúan las Vulnerabilidades (y Por Qué Falla)

Qué es CVSS

El Common Vulnerability Scoring System (CVSS) es el estándar global para cuantificar la severidad de las vulnerabilidades de software. Mantenido por FIRST (Forum of Incident Response and Security Teams), CVSS asigna a cada vulnerabilidad una puntuación numérica de 0.0 a 10.0 que refleja sus características técnicas intrínsecas.

Cuando se publica un CVE (Common Vulnerabilities and Exposures), una de las primeras preguntas que surgen es: "¿qué tan grave es?". CVSS intenta responder esa pregunta con una métrica estandarizada que permite comparar vulnerabilidades entre sí, independientemente del software afectado.

El sistema ha evolucionado a través de varias versiones. CVSS v2 (2007) fue ampliamente adoptado pero tenía limitaciones significativas. CVSS v3.0 (2015) y su revisión v3.1 (2019) mejoraron la granularidad y la precisión. CVSS v4.0 (publicado en noviembre de 2023) es la versión actual, con cambios sustanciales que intentan abordar las críticas acumuladas durante años.

A pesar de su ubicuidad, CVSS tiene una paradoja fundamental: es el estándar que todo el mundo usa y que casi todo el mundo critica. El propio director ejecutivo de FIRST ha afirmado que usar el base score solo para priorizar vulnerabilidades es "el método menos apto y preciso".

Los componentes del base score

El base score es la puntuación que aparece en los CVEs publicados por NIST NVD, en los advisories de los fabricantes, y en las herramientas de gestión de vulnerabilidades. Se calcula a partir de dos grupos de métricas que evalúan, respectivamente, cómo se explota la vulnerabilidad y cuál es su impacto.

Métricas de explotabilidad

Attack Vector (AV) describe desde dónde puede lanzarse el ataque. Los valores, de mayor a menor severidad, son:

• Network (N): el atacante puede explotar la vulnerabilidad de forma remota a través de la red. La mayoría de las vulnerabilidades web, de servicios de red y de protocolos son Network.
• Adjacent (A): el atacante necesita estar en la misma red local (mismo segmento de broadcast, Bluetooth, Wi-Fi). Vulnerabilidades de protocolos de red local o de descubrimiento de servicios.
• Local (L): el atacante necesita acceso local al sistema. Puede ser un usuario con shell, o el ataque requiere que el usuario abra un archivo malicioso (un PDF, un documento Office).
• Physical (P): el atacante necesita acceso físico al dispositivo. Vulnerabilidades de USB, NFC o de acceso a hardware.

Attack Complexity (AC) mide las condiciones que el atacante debe superar más allá de lo que puede controlar. En CVSS v3.1, Low significa que no hay condiciones especiales (el exploit funciona siempre) y High significa que depende de condiciones fuera del control del atacante (race condition, configuración específica, estado de la memoria).

Privileges Required (PR) indica si el atacante necesita credenciales:

• None: no necesita autenticación.
• Low: necesita una cuenta de usuario normal.
• High: necesita una cuenta con privilegios administrativos.

User Interaction (UI) indica si la víctima debe realizar alguna acción:

• None: el ataque funciona sin que la víctima haga nada (como un gusano de red).
• Required: la víctima debe realizar una acción (abrir un archivo, visitar una página, hacer clic en un enlace).

Métricas de impacto

Confidentiality (C), Integrity (I), Availability (A) miden el impacto en las tres propiedades de la seguridad de la información. Cada una puede ser:

• High: pérdida total del atributo. El atacante puede leer toda la información (C:H), modificar cualquier dato (I:H), o causar denegación de servicio completa (A:H).
• Low: pérdida parcial. Acceso limitado a información, modificación restringida, o degradación del servicio.
• None: sin impacto en ese atributo.

Scope (en CVSS v3.1)

Scope es la métrica más controvertida de CVSS v3.1. Indica si la explotación de la vulnerabilidad afecta solo al componente vulnerable (Unchanged) o también a otros componentes del sistema (Changed). Por ejemplo, una vulnerabilidad en una máquina virtual que permite escapar del sandbox y afectar al host tiene Scope:Changed. Este concepto fue difícil de aplicar de forma consistente y fue eliminado en CVSS v4.0.

Cómo leer un vector string

El vector string de CVSS codifica todas las métricas en una cadena de texto compacta. Aprender a leerlo permite evaluar rápidamente una vulnerabilidad sin necesidad de buscar la descripción completa.

Ejemplo con CVSS v3.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → Score: 9.8

Desglosado:

• AV:N (Attack Vector: Network): ataque remoto.
• AC:L (Attack Complexity: Low): sin condiciones especiales.
• PR:N (Privileges Required: None): sin autenticación.
• UI:N (User Interaction: None): sin acción de la víctima.
• S:U (Scope: Unchanged): afecta solo al componente vulnerable.
• C:H/I:H/A:H: impacto total en confidencialidad, integridad y disponibilidad.

Este vector describe una vulnerabilidad de ejecución remota de código sin autenticación: el peor escenario posible. Es el vector típico de las vulnerabilidades más críticas (Log4Shell, EternalBlue, ProxyLogon).

Ejemplo con restricciones

CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N → Score: 3.7

• AV:N: remoto.
• AC:H: requiere condiciones específicas (race condition, configuración rara).
• PR:L: necesita una cuenta de usuario.
• UI:R: la víctima debe realizar una acción.
• C:L/I:L/A:N: acceso parcial a información, modificación limitada, sin impacto en disponibilidad.

Esta vulnerabilidad es significativamente menos grave: requiere autenticación, interacción del usuario, y condiciones difíciles de replicar.

Ejemplos con CVEs reales

CVE-2021-44228 (Log4Shell): CVSS 10.0. Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Ejecución remota de código sin autenticación, con impacto que trasciende el componente vulnerable (Scope:Changed).

CVE-2017-0144 (EternalBlue): CVSS 8.1. Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Similar a Log4Shell pero con Attack Complexity High porque la explotación requiere condiciones específicas de memoria.

CVE-2023-34362 (MOVEit): CVSS 9.8. Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Inyección SQL remota sin autenticación, el patrón 9.8 estándar.

Por qué CVSS falla como herramienta de priorización

A pesar de su utilidad para describir las características técnicas de una vulnerabilidad, CVSS tiene limitaciones fundamentales cuando se usa como herramienta principal de priorización.

La inflación de scores críticos

En 2025, se publicaron más de 48.000 CVEs. Una proporción creciente recibe puntuaciones de 7.0 o superior (High o Critical). Cuando todo es crítico, nada es crítico. Los equipos de seguridad que priorizan exclusivamente por CVSS base score se enfrentan a cientos o miles de vulnerabilidades "críticas" que no pueden abordar simultáneamente.

La inflación tiene múltiples causas. Los vendors tienden a puntuar sus propias vulnerabilidades con severidad alta para demostrar responsabilidad. Las herramientas de análisis automático a menudo asignan el peor caso posible. Y la estructura del CVSS facilita que vulnerabilidades remotas sin autenticación alcancen automáticamente el rango Critical, independientemente de si son explotables en la práctica.

No considera la explotación en el mundo real

El base score no refleja si alguien está explotando la vulnerabilidad. Un CVSS 9.8 que solo existe como bug teórico y un CVSS 9.8 que está siendo explotado activamente por grupos de ransomware reciben la misma puntuación. Para un equipo de operaciones de seguridad, la diferencia es enorme: uno puede esperar a la próxima ventana de mantenimiento, el otro necesita un parche de emergencia.

CVSS incluye métricas temporales (Exploit Code Maturity, Remediation Level, Report Confidence) que podrían capturar esta información, pero en la práctica casi nunca se usan. El NVD de NIST solo publica base scores. La mayoría de herramientas de gestión de vulnerabilidades solo muestran base scores. Las métricas temporales requieren actualización continua que nadie mantiene.

El contexto importa (y CVSS no lo captura)

Una misma vulnerabilidad tiene riesgos radicalmente diferentes según el contexto:

• Un servidor web expuesto a Internet con la vulnerabilidad: riesgo altísimo.
• El mismo servidor en una red segmentada accesible solo por VPN corporativa: riesgo menor.
• El mismo software en un entorno de desarrollo con datos sintéticos: riesgo bajo.

CVSS mide la vulnerabilidad en abstracto, no el riesgo para tu organización. Las métricas ambientales (Environmental Metrics) de CVSS permiten ajustar la puntuación según el contexto, pero, de nuevo, casi nadie las usa porque requieren evaluación manual por cada vulnerabilidad en cada entorno.

El problema del Scope

En CVSS v3.1, la métrica Scope fue fuente constante de inconsistencia. La distinción entre "afecta solo al componente vulnerable" y "afecta a otros componentes" era subjetiva y se aplicaba de forma diferente según el analista o el vendor. Una vulnerabilidad de escape de sandbox tenía claramente Scope:Changed, pero ¿qué pasa con una vulnerabilidad en un servicio que, al ser comprometido, da acceso a la red interna? Diferentes analistas llegaban a conclusiones diferentes, produciendo puntuaciones inconsistentes para vulnerabilidades equivalentes.

CVSS v4.0: qué cambió

FIRST publicó CVSS v4.0 en noviembre de 2023, con cambios significativos diseñados para abordar las críticas más persistentes.

Eliminación del Scope

El Scope desaparece. En su lugar, el impacto se divide explícitamente en dos conjuntos de métricas:

• Vulnerable System Impact (VC, VI, VA): impacto en confidencialidad, integridad y disponibilidad del sistema vulnerable.
• Subsequent System Impact (SC, SI, SA): impacto en sistemas "posteriores" o conectados.

Esta separación es más precisa que el binario Scope:Changed/Unchanged y reduce las inconsistencias de scoring.

Nueva métrica: Attack Requirements (AT)

CVSS v4.0 introduce Attack Requirements, que captura condiciones fuera del control del atacante que deben existir para que la explotación sea posible. Ejemplos: una race condition que requiere ganar una carrera de timing, una topología de red específica, o un estado particular del sistema. Esto complementa a Attack Complexity (que en v4.0 se limita a las dificultades técnicas que el atacante puede superar con esfuerzo).

User Interaction expandida

En CVSS v3.1, User Interaction era binaria: None o Required. En v4.0, se expande a tres valores:

• None: sin interacción necesaria.
• Passive: la víctima realiza una acción rutinaria sin ingeniería social específica (abrir un correo, visitar una página habitual). El atacante no necesita convencer a la víctima de hacer algo inusual.
• Active: la víctima debe realizar una acción no rutinaria que normalmente requiere ingeniería social (ejecutar un archivo desconocido, deshabilitar una protección).

Threat Metrics (antes Temporal)

Las métricas temporales se renombran a Threat Metrics y se simplifican. El foco es la explotación real: ¿existe exploit público? ¿Se ha observado explotación activa? Esta simplificación busca que las métricas se usen de verdad, algo que no ocurría con las temporales de v3.1.

Métricas suplementarias

CVSS v4.0 introduce métricas suplementarias opcionales que proporcionan contexto adicional:

• Automatable: ¿puede automatizarse el ataque? Un ataque automatizable es más peligroso que uno que requiere intervención humana por cada objetivo.
• Recovery: ¿el sistema se recupera automáticamente tras el ataque, requiere intervención manual, o es irrecuperable?
• Value Density: ¿el sistema afectado contiene datos de alto valor o es un endpoint genérico?
• Provider Urgency: la urgencia que el fabricante del software asigna a la vulnerabilidad.

Nomenclatura de scores

CVSS v4.0 introduce nomenclatura específica para diferentes combinaciones de métricas:

• CVSS-B: solo base metrics.
• CVSS-BT: base + threat metrics.
• CVSS-BE: base + environmental metrics.
• CVSS-BTE: base + threat + environmental (el más completo).

Alternativas y complementos a CVSS

El reconocimiento de las limitaciones de CVSS ha impulsado el desarrollo de sistemas alternativos que abordan la priorización desde ángulos diferentes.

CISA KEV (Known Exploited Vulnerabilities)

El catálogo KEV de CISA es la lista más directa de "vulnerabilidades que importan ahora mismo". Si un CVE está en el KEV, significa que CISA tiene evidencia de explotación activa en el mundo real. No es una puntuación numérica, es una lista binaria: estás en la lista o no estás.

Para la priorización, la lógica es simple: si está en el KEV, es prioridad inmediata, independientemente del CVSS score. Un CVSS 7.5 en el KEV es más urgente que un CVSS 10.0 que no está siendo explotado.

EPSS (Exploit Prediction Scoring System)

EPSS, desarrollado por FIRST (la misma organización detrás de CVSS), estima la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días. Produce un valor de 0 a 1 (0% a 100% de probabilidad).

EPSS v3.0 analiza más de 6 millones de intentos de explotación observados e incorpora datos de proveedores de threat intelligence, el catálogo KEV de CISA, y las características de la vulnerabilidad. A diferencia de CVSS, EPSS es dinámico: la probabilidad cambia con el tiempo a medida que aparecen nuevos datos.

La combinación de CVSS (severidad) y EPSS (probabilidad de explotación) es más informativa que cualquiera de las dos métricas por separado. Un CVSS 9.8 con EPSS 0.001 (0,1%) puede esperar; un CVSS 7.0 con EPSS 0.90 (90%) no.

SSVC (Stakeholder-Specific Vulnerability Categorization)

SSVC, desarrollado por CISA y el SEI (Software Engineering Institute) de Carnegie Mellon, adopta un enfoque radicalmente diferente. En lugar de producir una puntuación numérica, SSVC usa árboles de decisión que consideran:

• Exploitation: ¿existe explotación activa (Active), PoC público (PoC), o ninguna evidencia (None)?
• Automatability: ¿el ataque puede lanzarse de forma automatizada contra múltiples objetivos?
• Technical Impact: ¿el impacto técnico es parcial o total?

El resultado es una de cuatro decisiones de acción:

• Track: monitorizar, no requiere acción inmediata.
• Track:* monitorizar con atención, puede requerir acción pronto.
• Attend: intervenir dentro del próximo ciclo de parcheo.
• Act: intervenir inmediatamente, fuera de ciclo.

SSVC es más útil para la toma de decisiones porque produce acciones en lugar de números. Su limitación es que la evaluación es manual y no escala fácilmente a miles de vulnerabilidades pendientes.

VPR (Vulnerability Priority Rating) de Tenable

Tenable desarrolló VPR como una puntuación de 0 a 10 que combina la severidad técnica con la actividad de amenazas. VPR incorpora datos de explotación, disponibilidad de exploit, y la madurez del código de explotación. Es propietaria y específica de la plataforma Tenable, pero ilustra la tendencia de la industria hacia métricas que integren el contexto de amenazas.

LEV (Likely Exploited Vulnerabilities) de NIST

Introducida por NIST en 2025, LEV estima la probabilidad de que una vulnerabilidad ya haya sido explotada (no de que vaya a serlo, como EPSS). Se basa en el análisis histórico de scores EPSS y patrones de explotación. LEV complementa a EPSS proporcionando una estimación retrospectiva.

Cómo usar CVSS correctamente

CVSS no es inútil; es insuficiente cuando se usa solo. Estas son las prácticas que maximizan su valor:

Nunca usar base score solo. Combinarlo con CISA KEV (¿está siendo explotada?), EPSS (¿va a ser explotada?) y contexto organizacional (¿el activo está expuesto? ¿contiene datos sensibles?).

Ajustar con métricas ambientales. Si tu organización tiene la capacidad, calcular el score ambiental considerando los controles compensatorios existentes y la criticidad de los activos afectados.

Tratar CVSS como un descriptor, no como un decisor. El vector string describe las características técnicas de la vulnerabilidad. La decisión de cuándo y cómo parchear requiere información adicional que CVSS no proporciona.

Migrar a CVSS v4.0. La nueva versión aborda varios de los problemas más persistentes de v3.1. La transición requiere actualizar herramientas y procesos, pero el resultado es una métrica más precisa y menos inflada.

Automatizar lo que sea posible. Para organizaciones con miles de vulnerabilidades pendientes, la priorización manual por cada CVE no es viable. Las herramientas que integran CVSS, EPSS, KEV y el inventario de activos para producir una priorización automatizada son el camino práctico hacia una gestión de vulnerabilidades efectiva.