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 común gestionado por el CVE Program para que fabricantes, investigadores, defensores y herramientas compartan una referencia consistente.
• CVSS (Common Vulnerability Scoring System): responde a ¿qué características de severidad técnica tiene? Es un estándar abierto mantenido por FIRST que expresa severidad mediante métricas y un vector reproducible.
• Prioridad / riesgo: responde a ¿qué debo atender antes en mi entorno? Requiere combinar severidad con aplicabilidad, exposición, criticidad del activo, impacto, evidencia de explotación (CISA KEV) y probabilidad (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.

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

Un identificador CVE sigue la sintaxis CVE-AÑO-SECUENCIA. Según el proceso oficial del CVE Program, el año corresponde al año de reserva del ID o al año en que la vulnerabilidad se hizo pública; no indica necesariamente cuándo fue descubierta. La secuencia admite cuatro o más dígitos y no tiene un límite fijo de longitud.

La asignación la realizan las CVE Numbering Authorities (CNA), organizaciones autorizadas para reservar IDs y publicar CVE Records dentro de su ámbito. RESERVED es el estado inicial: el ID ya fue reservado, pero los detalles del CVE Record todavía no se han publicado en la lista pública. No conviene interpretar RESERVED como sinónimo de “vulnerabilidad falsa” ni asumir detalles que aún no están disponibles.

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

CVSS es un estándar abierto mantenido por FIRST para comunicar las características y la severidad de vulnerabilidades. La especificación oficial CVSS v4.0 mantiene una puntuación de 0.0 a 10.0 y una escala cualitativa:

• 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 vigente CVSS v4.0 refina cómo se comunica la severidad y el contexto técnico frente a v3.1. FIRST destaca, entre otros, estos cambios:

• 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 v4.0: Base, Threat, Environmental y Supplemental #

CVSS v4.0 se expresa mediante un vector estructurado (por ejemplo, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/...). La especificación organiza las métricas en cuatro grupos:

1. Base Metrics: describen características de la vulnerabilidad que son constantes en el tiempo y entre entornos, incluyendo explotabilidad e impacto en el sistema vulnerable y, cuando corresponde, en sistemas posteriores.
2. Threat Metrics: incorporan información que puede cambiar con el tiempo, especialmente la madurez de explotación (Exploit Maturity).
3. Environmental Metrics: permiten adaptar el análisis a requisitos de seguridad y condiciones concretas del entorno mediante métricas modificadas. Son útiles para contextualizar severidad, pero no sustituyen un análisis de riesgo empresarial.
4. Supplemental Metrics: aportan información adicional —como Safety, Automatable, Recovery o Vulnerability Response Effort— y no modifican la puntuación final CVSS-BTE.

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

La propia documentación del NVD recuerda que CVSS es una medida de severidad, no una medida completa de riesgo. Un CVSS 9.8 puede requerir menos urgencia relativa si el producto no es aplicable, el activo está aislado y existen controles efectivos; mientras que un CVSS 7.5 expuesto a Internet, explotado activamente y sobre un activo crítico puede merecer atención anterior. La prioridad final exige contexto, no solo ordenar números.

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

El CISA Known Exploited Vulnerabilities (KEV) Catalog reúne vulnerabilidades para las que existe evidencia de explotación activa y una acción de remediación clara. CISA recomienda utilizar KEV como entrada prioritaria del proceso de gestión de vulnerabilidades. Estar en KEV debe elevar fuertemente la urgencia, pero una organización sigue necesitando confirmar aplicabilidad, activos afectados, mitigaciones disponibles y restricciones operativas. Los plazos obligatorios de CISA aplican específicamente a los organismos federales civiles estadounidenses cubiertos por sus directivas, no de forma universal a todas las empresas.

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

El Exploit Prediction Scoring System (EPSS), mantenido por FIRST y operando en 2026 con su generación v5, publica diariamente una probabilidad entre 0 y 1 de que un CVE publicado sea explotado en el mundo real durante los próximos 30 días. EPSS no es un score completo de riesgo: no conoce la criticidad de tus activos ni tus controles. Su valor está en complementar señales como CVSS y KEV con una estimación probabilística de explotación.

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

El modelo ISEEP para priorizar vulnerabilidades con criterio #

Importante: ISEEP es una mnemotecnia didáctica utilizada en esta guía para ordenar el razonamiento; no es un estándar de FIRST, NIST, CISA ni CVE.

El framework operativo VULNERA paso a paso #

VULNERA es otro modelo práctico propio de esta guía. Úsalo como checklist operativo para no reducir la priorización a un único score.

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 CISA KEV, EPSS y fuentes de inteligencia para distinguir explotación confirmada, probabilidad y simple disponibilidad de un PoC.
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 o actualización cuando proceda, despliega una mitigación temporal, reduce exposición o documenta una aceptación formal de riesgo con propietario y fecha de revisión.

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 servicio presente en un entorno de pruebas aislado de redes no confiables, sin datos sensibles y con controles compensatorios; no figura en KEV y su aplicabilidad ha sido validada.
• Vulnerabilidad B (CVSS 8.1 High): afecta a una pasarela VPN corporativa expuesta a Internet, está presente en el activo real y figura en CISA KEV con evidencia de explotación activa.

Si solo ordenas por el número base, A aparecería primero. Un proceso de priorización basado en riesgo probablemente adelantará B porque combina exposición, aplicabilidad, criticidad y explotación confirmada. Esto no “rebaja” la severidad de A: simplemente separa severidad de urgencia operativa. En incidentes donde la explotación ya está ocurriendo, conecta esta decisión con el proceso de Incident Response y con el análisis de ransomware desde Blue Team.

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: convierte hallazgos relevantes en contexto de detección, threat hunting, respuesta y reducción de superficie. Si estás construyendo esa ruta, consulta el Blue Team roadmap y la guía de Incident Response.
• Red Team & Pentesting: valida, dentro de un alcance autorizado, si una vulnerabilidad es explotable en las condiciones reales del cliente. Para profundizar, revisa cómo ser pentester y las herramientas de hacking ético y pentesting.
• GRC: define criterios y SLAs basados en riesgo, gestiona excepciones y aceptación de riesgo residual, y conecta la vulnerabilidad técnica con controles de gestión como ISO 27001 y su tratamiento de vulnerabilidades técnicas.

Conclusión y errores frecuentes al evaluar vulnerabilidades #

El volumen de vulnerabilidades publicadas hace inviable tratar todos los hallazgos con la misma urgencia. La conclusión operativa es simple: CVE identifica; CVSS comunica severidad; KEV aporta evidencia de explotación; EPSS estima probabilidad; y tu entorno determina la prioridad final. Antes de remediar, valida aplicabilidad y activo afectado; después combina amenaza, exposición, criticidad e impacto. Ese orden reduce tanto el riesgo de ignorar vulnerabilidades realmente peligrosas como el de consumir recursos persiguiendo únicamente puntuaciones altas.