CVE y CVSS: qué son y cómo priorizar vulnerabilidades correctamente

Respuesta rápida: qué son CVE y CVSS y por qué son diferentes #

La confusión más habitual en ciberseguridad es mezclar identificación, severidad y riesgo. Cada estándar responde a una pregunta distinta:

• CVE (Common Vulnerabilities and Exposures): Responde a ¿De qué vulnerabilidad concreta estamos hablando? Es un identificador único estandarizado (ej. CVE-2026-12345) para que fabricantes, defensores y escáneres compartan una referencia común.
• CVSS (Common Vulnerability Scoring System): Responde a ¿Qué características técnicas de severidad tiene? Es un marco de FIRST que genera una puntuación de 0.0 a 10.0 basada en métricas de explotación intrínsecas.
• Riesgo Empresarial: Responde a ¿Qué impacto real produce en mi infraestructura y cuándo debo actuar? Requiere cruzar la severidad técnica con la exposición del activo, la explotación activa (CISA KEV) y la probabilidad estadística (EPSS).

Este concepto se evalúa habitualmente en procesos de selección: puedes repasar cómo justificarlo en nuestra guía de preguntas de entrevista técnica de ciberseguridad y aplicarlo en el marco de gobernanza técnica con qué es GRC en ciberseguridad.

Certificación Internacional de Referencia

CompTIA Security+ SY0-701: Práctica + Examen Completo

Aprende la clasificación formal de amenazas, vulnerabilidades, vectores de ataque y controles de remediación requeridos por el estándar de la industria.

Qué es un CVE: estructura, asignación y estado RESERVED #

Un registro CVE sigue la sintaxis CVE-AÑO-SECUENCIA. El año representa la fecha de reserva o publicación dentro del programa, no necesariamente el momento exacto en que fue descubierta. La secuencia numérica no está limitada a 4 dígitos y puede contener 5 o más cifras.

La asignación la realizan las CNA (CVE Numbering Authorities), que agrupan a fabricantes, centros de respuesta a incidentes e investigadores autorizados en todo el mundo. Cuando una vulnerabilidad se encuentra en coordinación antes de su divulgación oficial, recibe el estado RESERVED: el ID existe para coordinar parches, pero los detalles técnicos permanecen confidenciales.

Qué es CVSS y cómo interpretar la puntuación oficial #

CVSS es un estándar abierto mantenido por FIRST que traduce las características de un fallo a una escala cualitativa oficial:

• 0.0: None (Informativa / Sin impacto)
• 0.1 – 3.9: Low (Severidad Baja)
• 4.0 – 6.9: Medium (Severidad Media)
• 7.0 – 8.9: High (Severidad Alta)
• 9.0 – 10.0: Critical (Severidad Crítica)

Novedades de CVSS v4.0 frente a CVSS v3.1 #

La versión actual CVSS v4.0 introdujo mejoras estructurales para evitar la inflación artificial de puntuaciones:

• Nuevo Attack Requirements (AT): Separa las condiciones previas obligatorias de ejecución (como condiciones de carrera o configuraciones de red específicas) de la complejidad pura del exploit (Attack Complexity).
• Interacción de Usuario Granular (UI): Distingue entre interacción pasiva (Passive) e interacción activa (Active).
• Impacto en Sistemas Posteriores: Sustituye la métrica ambigua de Scope por una evaluación explícita del impacto en el sistema vulnerable (Vulnerable System) y en sistemas dependientes (Subsequent System).
• Threat Metrics simplificado: Sustituye el antiguo grupo temporal por métricas de amenaza centradas en la madurez del exploit (Exploit Maturity).
• Supplemental Metrics: Parámetros complementarios (Seguridad física, Automatización, Esfuerzo de respuesta) que aportan contexto sin alterar la nota matemática.

Desglose del vector CVSS: Base, Threat y Environmental Metrics #

Una puntuación como 9.8 es el resultado de un vector estructurado (ej. CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/...). Se dividen en tres grupos:

1. Base Metrics: Miden la explotabilidad técnica intrínseca (Vector de Ataque, Privilegios Requeridos, Complejidad) y el impacto en Confidencialidad, Integridad y Disponibilidad.
2. Threat Metrics: Reflejan el estado de la amenaza en el mundo real en un momento dado (si existe código de prueba de concepto funcional o ataques en curso).
3. Environmental Metrics: El grupo más importante para tu empresa: adapta la severidad considerando los controles compensatorios locales y la criticidad del sistema afectado.

Por qué CVSS Base mide severidad técnica y no riesgo empresarial #

El propio consorcio FIRST establece de forma taxativa: CVSS Base mide severidad técnica, no riesgo de negocio. Un fallo crítico en una máquina de laboratorio aislada y sin datos tiene severidad 9.8, pero su riesgo para la continuidad de la empresa es prácticamente nulo. Por el contrario, un CVSS 7.5 en un cortafuegos perimetral con exploit público activo representa un riesgo inminente.

CISA KEV: el catálogo de vulnerabilidades explotadas en el mundo real #

El catálogo CISA KEV (Known Exploited Vulnerabilities) lista las vulnerabilidades para las que la agencia estadounidense tiene evidencia confirmada de explotación activa por parte de ciberdelincuentes. Cuando una vulnerabilidad entra en KEV, la prioridad de parcheo debe adelantarse de inmediato, independientemente de si su CVSS es 7.0 o 9.8.

EPSS v5: estimación probabilística de explotación a 30 días #

El Exploit Prediction Scoring System (EPSS), desarrollado por FIRST y actualizado a su versión EPSS v5, es un modelo predictivo que calcula la probabilidad (de 0 a 1 o de 0 % a 100 %) de que una vulnerabilidad sea explotada en los siguientes 30 días. Mientras KEV confirma el pasado y presente observado, EPSS predice la probabilidad futura a escala global.

Diferencia clave entre CVE, CWE y la base de datos NVD #

Concepto	Definición y Función	Ejemplo
CWE	Tipo genérico o clase de debilidad de código/diseño	CWE-89 (Inyección SQL)
CVE	Instancia concreta de vulnerabilidad en un producto específico	CVE-2024-3400 (Fallo en cortafuegos)
NVD (NIST)	Base de datos pública que enriquece CVEs con CVSS, CPE y referencias	Catálogo oficial en nvd.nist.gov

El modelo ISEEP para priorizar vulnerabilidades con criterio #

El framework operativo VULNERA paso a paso #

1. V — Verifica aplicabilidad: Confirma si la versión, módulo y configuración vulnerable están realmente activos en tu entorno.
2. U — Ubica el activo: Identifica el servidor, el propietario del sistema y su nivel de criticidad en el inventario.
3. L — Lee el vector CVSS: Analiza si requiere privilegios de administrador o interacción activa de un usuario.
4. N — Nivel de amenaza: Consulta si aparece registrada en CISA KEV o si existen PoCs públicos en repositorios.
5. E — Exposición de red: Revisa cortafuegos y segmentación para ver si el atacante puede alcanzar el puerto.
6. R — Riesgo de negocio: Evalúa si una brecha afectaría a bases de datos con datos sensibles o procesos productivos.
7. A — Actúa: Aplica el parche, despliega una mitigación temporal o documenta una excepción formal de riesgo.

Ejemplo práctico de priorización: un CVSS 8.1 urgente frente a un 9.8 aislado #

Imagina dos vulnerabilidades detectadas en tu infraestructura:

• Vulnerabilidad A (CVSS 9.8 Critical): Afecta a un servidor de pruebas sin salida a Internet, con autenticación local y sin datos de clientes. Sin exploit público en CISA KEV.
• Vulnerabilidad B (CVSS 8.1 High): Afecta a la pasarela VPN corporativa expuesta a Internet, con exploit funcional disponible y listada en CISA KEV con ataques masivos en curso.

Una política basada ciegamente en CVSS parchearía primero la máquina de pruebas. Un equipo maduro de ciberseguridad prioriza de inmediato la Vulnerabilidad B, protegiendo el perímetro de un compromiso inminente (el vector de acceso inicial más explotado en incidentes de ransomware corporativo).

Vulnerability Management vs. Patch Management y controles compensatorios #

La gestión de vulnerabilidades no se limita a aplicar actualizaciones de software. Si un parche no está disponible de inmediato o causaría una parada en un entorno crítico, los analistas recurren a controles compensatorios:

• Reglas de virtual patching en el WAF o IPS perimetral.
• Aislamiento del activo mediante segmentación de VLAN o cortafuegos.
• Deshabilitación temporal de la característica o servicio vulnerable en el sistema operativo.
• Monitorización intensiva en el SIEM/EDR para detectar intentos de explotación.

Impacto de CVE y CVSS en Red Team, Blue Team y GRC #

El manejo de vulnerabilidades interconecta todas las ramas operativas de la seguridad:

• Blue Team & SOC: Transforma alertas de vulnerabilidades en casos de uso de detección, threat hunting y respuesta a incidentes (guía de Incident Response).
• Red Team & Pentesting: Valida si una vulnerabilidad teórica es realmente explotable en las condiciones reales del cliente (cómo ser pentester).
• GRC: Establece políticas de SLAs de remediación basadas en riesgo real y gestiona la aceptación formal de riesgos residuales con los propietarios de activos, integrándolos en el control A.8.8 del SGSI bajo ISO 27001.

Conclusión y errores frecuentes al evaluar vulnerabilidades #

Con más de 20.000 nuevos registros CVE publicados trimestralmente, intentar solucionarlo todo sin filtro es inviable. Evita considerar CVSS como sinónimo de riesgo y combina siempre el vector técnico con KEV, EPSS y el contexto operativo de tu empresa.