CVSS y CVE: qué son, cómo funcionan y por qué importan en ciberseguridad [2026]

1. ¿Qué es CVE (Common Vulnerabilities and Exposures)?

CVE es un sistema de identificación estandarizado para vulnerabilidades de seguridad informática. Cada vulnerabilidad conocida públicamente recibe un identificador único con el formato CVE-AAAA-NNNNN, donde AAAA es el año de asignación y NNNNN es un número secuencial. Este sistema fue creado por MITRE Corporation en 1999 y desde entonces se ha convertido en el lenguaje común de la industria para referirse a fallos de seguridad.

El propósito principal de CVE es eliminar la ambigüedad. Antes de su existencia, un mismo fallo podía recibir nombres diferentes según el fabricante, el investigador que lo descubrió o la herramienta de escaneo que lo detectaba. Con CVE, cuando alguien menciona CVE-2021-44228 (Log4Shell), toda la comunidad de ciberseguridad sabe exactamente de qué vulnerabilidad se trata, qué software afecta y cuál es su alcance.

El programa CVE está gestionado por MITRE con el patrocinio de la Cybersecurity and Infrastructure Security Agency (CISA) del Departamento de Seguridad Nacional de Estados Unidos. Para escalar la asignación de identificadores, se creó una red de CNAs (CVE Numbering Authorities): organizaciones autorizadas para reservar y asignar identificadores CVE dentro de su ámbito. Empresas como Microsoft, Google, Red Hat, Apache y muchas otras actúan como CNAs, lo que permite que las vulnerabilidades reciban su identificador rápidamente, a menudo incluso antes de hacerse públicas.

2. ¿Qué es CVSS (Common Vulnerability Scoring System)?

CVSS es un marco abierto y estandarizado para evaluar la severidad de las vulnerabilidades de seguridad informática. Produce una puntuación numérica entre 0.0 y 10.0 — el CVSS score — que refleja las características intrínsecas de la vulnerabilidad y su impacto potencial. Este sistema es mantenido por FIRST (Forum of Incident Response and Security Teams), una organización global sin ánimo de lucro.

Entender qué es CVSS en ciberseguridad es fundamental porque permite a los equipos de seguridad priorizar de forma objetiva. Sin un sistema de puntuación estándar, cada organización tendría que inventar su propia escala, lo que haría imposible comparar la gravedad de vulnerabilidades entre distintos productos, fabricantes o informes. El CVSS proporciona un lenguaje numérico común que se integra en escáneres de vulnerabilidades, plataformas de gestión de parches, informes de auditoría y políticas de seguridad corporativas.

Es importante aclarar que el CVSS mide la severidad técnica, no el riesgo real para tu organización. Una vulnerabilidad con CVSS 9.8 en un servidor aislado sin acceso a Internet puede representar menos riesgo operativo que un CVSS 6.5 en un servidor web expuesto públicamente con datos sensibles. Por eso, los marcos de gestión de riesgos como SSVC (Stakeholder-Specific Vulnerability Categorization) complementan el CVSS con factores contextuales como la exposición, el valor del activo y la existencia de exploits activos.

3. Diferencia entre CVE y CVSS

Aunque CVE y CVSS se mencionan juntos con frecuencia, cumplen funciones completamente distintas dentro del ecosistema de gestión de vulnerabilidades. Entender la diferencia entre ambos es esencial para cualquier profesional que trabaje en seguridad informática, ya sea en un equipo Red Team o Blue Team.

En la práctica, cuando un investigador descubre una vulnerabilidad, primero solicita un CVE para que tenga un nombre único. Después, el NVD u otra autoridad asigna una puntuación CVSS basada en las características técnicas del fallo. Los equipos de seguridad luego usan ambos datos: el CVE para buscar información, parches y advisories, y el CVSS score para decidir la urgencia del parcheo.

4. Historia y evolución: de CVSS v2 a CVSS v4.0

El CVSS ha evolucionado significativamente desde su primera versión. Cada iteración ha buscado mejorar la precisión, reducir la ambigüedad y adaptarse a los cambios en el panorama de amenazas.

CVSS v4.0, publicado por FIRST en noviembre de 2023, representa el cambio más significativo en años. Elimina la métrica «Scope» — fuente habitual de confusión — y la reemplaza con métricas de impacto separadas para el sistema vulnerable y los sistemas posteriores. También introduce métricas suplementarias como Automatable, Recovery y Value Density, que permiten capturar características adicionales de la vulnerabilidad sin afectar la puntuación numérica base.

A pesar de que v4.0 es el estándar vigente, la transición es gradual. El NVD todavía muestra puntuaciones v3.1 para la mayoría de CVE existentes, y muchas herramientas de escaneo y gestión de vulnerabilidades están en proceso de adoptar la nueva versión. Si estás aprendiendo las diferentes ramas de la ciberseguridad, es recomendable familiarizarte con ambas versiones.

5. Métricas del CVSS v4.0

CVSS v4.0 organiza sus métricas en cuatro grupos. Cada grupo captura una dimensión diferente de la vulnerabilidad, desde sus características técnicas intrínsecas hasta factores que dependen del entorno específico de cada organización.

Métricas Base (Base Metrics)

Son las características permanentes de la vulnerabilidad que no cambian con el tiempo ni dependen del entorno. Incluyen:

Métricas de Amenaza (Threat Metrics)

Anteriormente llamadas «temporales», reflejan el estado actual de la explotabilidad. En v4.0, la métrica principal es Exploit Maturity (E), con valores que van desde Not Defined hasta Attacked (cuando hay explotación activa confirmada). Estos valores pueden cambiar a lo largo del tiempo a medida que se desarrollan exploits o se publican parches.

Métricas de Entorno (Environmental Metrics)

Permiten a cada organización personalizar la puntuación según la importancia del activo afectado en su infraestructura. Incluyen versiones modificadas de las métricas base y requisitos de seguridad específicos (Confidentiality, Integrity, Availability Requirements). Un hospital, por ejemplo, podría elevar la importancia de la disponibilidad en sistemas médicos críticos.

Métricas Suplementarias (Supplemental Metrics)

Son completamente nuevas en v4.0 y no afectan la puntuación numérica, pero proporcionan contexto adicional valioso:

• Automatable (AU) — ¿Se puede automatizar la explotación a escala?
• Recovery (R) — ¿Puede el sistema recuperarse tras la explotación?
• Value Density (V) — ¿Cuántos recursos valiosos se obtienen por ataque?
• Vulnerability Response Effort (RE) — ¿Cuánto esfuerzo requiere remediar la vulnerabilidad?
• Provider Urgency (U) — Urgencia valorada por el proveedor del producto afectado.
• Safety (S) — ¿La explotación puede causar daño físico o ambiental?

6. Cómo se calcula el CVSS Score

El cálculo del CVSS score no es una simple suma de valores. FIRST define una fórmula matemática compleja que combina las métricas base mediante funciones que modelan la relación entre explotabilidad e impacto. El resultado es un número con un decimal que va de 0.0 (sin impacto) a 10.0 (severidad máxima).

En CVSS v4.0, el cálculo utiliza un sistema de macro-vectores que agrupan combinaciones de métricas en niveles de severidad equivalente. A diferencia de versiones anteriores donde la fórmula era puramente algebraica, v4.0 emplea una tabla de lookup combinada con interpolación para producir la puntuación final. Esto reduce las anomalías donde cambios menores en una métrica producían saltos desproporcionados en la puntuación.

En CVSS v4.0 se definen cuatro tipos de puntuación según las métricas utilizadas:

La recomendación de FIRST es que las organizaciones no se limiten al CVSS-B sino que calculen al menos el CVSS-BT cuando exista información de amenazas disponible, y el CVSS-BTE para los activos más críticos.

7. Rangos de severidad CVSS

La puntuación numérica del CVSS se traduce en categorías cualitativas de severidad que facilitan la comunicación entre equipos técnicos, directivos y reguladores. Estos rangos son los mismos para CVSS v3.x y v4.0.

Es importante recordar que estos rangos y plazos son orientativos. Cada organización debe definir sus propios SLA de remediación basándose no solo en el CVSS, sino también en la criticidad del activo, la exposición a Internet, la existencia de exploits públicos y el contexto de negocio. Un equipo Blue Team en un CTF puede practicar con escenarios donde la priorización basada en CVSS es clave para defender la infraestructura.

8. CVSS Calculator: herramientas para calcular puntuaciones

Nadie calcula el CVSS a mano: existen herramientas — los llamados CVSS calculators — que permiten seleccionar los valores de cada métrica y obtener la puntuación y el vector de forma inmediata. Estas herramientas son esenciales tanto para investigadores que reportan vulnerabilidades como para analistas que necesitan recalcular puntuaciones con métricas de entorno.

El vector string es una representación compacta de todas las métricas seleccionadas. En v4.0, tiene el formato: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Este vector se incluye en advisories, bases de datos y reportes para que cualquiera pueda reproducir exactamente la puntuación.

9. CVE en la práctica: el ciclo de vida de una vulnerabilidad

Entender cómo un CVE nace, se publica y se gestiona es clave para cualquier profesional que trabaje en seguridad. El proceso involucra múltiples actores y puede variar en duración desde días hasta meses, dependiendo de la complejidad del fallo y la responsabilidad del fabricante.

No todas las vulnerabilidades siguen este camino ideal. En el caso de las zero-day, la vulnerabilidad se explota activamente antes de que exista un parche o incluso un CVE. En estas situaciones, los equipos de respuesta a incidentes deben actuar con la información disponible — a menudo un indicador de compromiso (IoC) o un advisory preliminar del fabricante — mientras el CVE y la puntuación CVSS se asignan retroactivamente.

También existen vulnerabilidades que reciben un CVE pero nunca obtienen una puntuación CVSS del NVD, generalmente por falta de información técnica suficiente o porque la vulnerabilidad se disputa. En estos casos, los investigadores de seguridad y fabricantes pueden proporcionar su propia evaluación de severidad.

10. Bases de datos de vulnerabilidades: NVD, MITRE y más

Las bases de datos de vulnerabilidades son el motor que da vida a los identificadores CVE y las puntuaciones CVSS. Sin ellas, la información sobre vulnerabilidades estaría dispersa en advisories de fabricantes, listas de correo y blogs de investigadores. Estas plataformas centralizan, enriquecen y distribuyen la información de seguridad que necesitan los equipos de defensa.

Es habitual que un analista de seguridad consulte varias de estas bases de datos simultáneamente. El NVD proporciona la puntuación CVSS oficial, pero puede tardar días o semanas en procesar un CVE nuevo. Mientras tanto, los advisories del fabricante, Vulners o GitHub Advisory pueden tener información más actualizada. La combinación de múltiples fuentes es una práctica recomendada en cualquier programa de gestión de vulnerabilidades.

11. CVSS y CVE en el trabajo diario de ciberseguridad

Los identificadores CVE y las puntuaciones CVSS no son conceptos teóricos: son herramientas que se usan todos los días en múltiples roles dentro de la ciberseguridad. Desde el analista de SOC que triagea alertas hasta el pentester que redacta un informe, pasando por el gestor de vulnerabilidades que prioriza parches, estos estándares están presentes en prácticamente todo el flujo de trabajo de seguridad.

En un SOC (Security Operations Center)

Los analistas de SOC reciben alertas de escáneres de vulnerabilidades que incluyen el CVE y el CVSS score. Utilizan esta información para priorizar qué vulnerabilidades investigar primero, correlacionándola con feeds de inteligencia de amenazas que indican si existe explotación activa. Un CVE con CVSS 9.8 y exploit público conocido se escala inmediatamente; uno con CVSS 4.0 sin exploit conocido puede esperar al siguiente ciclo de parcheo.

En pentesting y Red Team

Los pentesters usan los CVE para identificar vulnerabilidades conocidas en los sistemas que auditan. Las herramientas de hacking ético como Nmap, Metasploit y Nessus asocian cada hallazgo con su CVE correspondiente. En los informes de pentesting, las vulnerabilidades se clasifican por CVSS para que el cliente entienda la prioridad de remediación. Un buen informe de Red Team no solo lista CVEs, sino que demuestra el impacto real de cada uno en el contexto del cliente.

En gestión de vulnerabilidades

Los programas de gestión de vulnerabilidades definen SLAs de remediación basados en los rangos de severidad CVSS: por ejemplo, parche en 48 horas para críticas, 15 días para altas, 30 días para medias y 90 días para bajas. Los dashboards de gestión agregan los CVEs abiertos por severidad, antigüedad y activo, proporcionando visibilidad ejecutiva del riesgo técnico de la organización.

En cumplimiento y auditoría

Normativas como PCI DSS exigen que las vulnerabilidades con CVSS superior a 4.0 se remedien en plazos específicos. Los auditores verifican que las organizaciones tienen un proceso documentado para identificar, priorizar y remediar CVEs, y que los escáneres de vulnerabilidades se ejecutan con la frecuencia requerida. El CVSS proporciona la métrica objetiva que tanto auditores como auditados necesitan para evaluar el cumplimiento.

12. Preguntas frecuentes