VULNERABILIDADES, CVE Y CVSS

Vulnerabilidades, CVE y CVSS

Comprende cómo se identifican, describen, valoran y priorizan las vulnerabilidades que afectan a sistemas, aplicaciones y servicios.

CONCEPTOS

Qué es una vulnerabilidad

Una vulnerabilidad es una debilidad que puede afectar a la seguridad de un sistema, aplicación, servicio, dispositivo o componente.

Puede estar relacionada con errores de software, configuraciones incorrectas, mecanismos de autenticación inadecuados, permisos excesivos, protocolos, dependencias o procesos de administración.

Activo
↓
Vulnerabilidad
↓
Posible aprovechamiento
↓
Impacto sobre la seguridad

La existencia de una vulnerabilidad no significa necesariamente que se esté produciendo un incidente. Indica que existe una debilidad que debe evaluarse dentro de su contexto.

ORIGEN

De dónde pueden surgir las vulnerabilidades

Las vulnerabilidades pueden aparecer en diferentes capas de un entorno tecnológico.

errores en el código de una aplicación;
software o componentes sin actualizar;
configuraciones inseguras;
servicios expuestos innecesariamente;
permisos excesivos;
mecanismos de autenticación deficientes;
dependencias vulnerables;
protocolos o tecnologías obsoletas;
configuraciones predeterminadas inadecuadas;
errores en procesos de administración.

Por ello, la gestión de vulnerabilidades no debe limitarse únicamente a buscar errores en aplicaciones. También requiere revisar sistemas, configuraciones, dependencias y exposición.

DIFERENCIAS

Vulnerabilidad, amenaza y riesgo

Estos conceptos están relacionados, pero no significan lo mismo.

Vulnerabilidad:debilidad presente en un activo, sistema o proceso.
Amenaza:circunstancia o agente capaz de causar un efecto adverso.
Riesgo:valoración de las posibles consecuencias asociadas a una situación de seguridad dentro de un contexto.

Activo
↓
Vulnerabilidad
↓
Amenaza relevante
↓
Posible impacto
↓
Riesgo

Una misma vulnerabilidad puede representar niveles de riesgo diferentes según el activo afectado, su exposición y las medidas de protección existentes.

IDENTIFICACIÓN

Qué es CVE

CVE, Common Vulnerabilities and Exposures, proporciona identificadores comunes para vulnerabilidades de seguridad divulgadas públicamente.

Un identificador CVE permite que fabricantes, investigadores, administradores, herramientas y bases de datos hagan referencia a la misma vulnerabilidad utilizando una denominación común.

CVE-2026-12345 CVE → sistema de identificación
2026 → año asociado al identificador
12345 → número identificador

El ejemplo anterior es únicamente ilustrativo. Un identificador CVE no indica por sí mismo la gravedad, el impacto real ni la prioridad que debe tener una vulnerabilidad dentro de una organización.

IMPORTANTE

Qué información aporta un CVE

El identificador CVE sirve principalmente para identificar una vulnerabilidad de manera consistente.

Conviene diferenciar el identificador de otras fuentes de información que pueden añadir datos como:

productos y versiones afectados;
descripción técnica;
referencias del fabricante;
actualizaciones disponibles;
métricas de severidad;
información sobre explotación;
medidas de mitigación.

CVE
→ identifica CVSS
→ ayuda a valorar severidad Contexto del entorno
→ ayuda a determinar prioridad

Por tanto, CVE y CVSS cumplen funciones diferentes y no deben utilizarse como términos equivalentes.

SEVERIDAD

Qué es CVSS

CVSS, Common Vulnerability Scoring System, es un estándar abierto para expresar características relacionadas con la severidad de una vulnerabilidad.

El sistema utiliza diferentes métricas para representar propiedades de la vulnerabilidad y producir información que puede ayudar en su evaluación.

Características de la vulnerabilidad
↓
Métricas CVSS
↓
Vector
↓
Puntuación
↓
Información sobre severidad

La puntuación CVSS es una referencia útil, pero no representa por sí sola el riesgo específico que una vulnerabilidad supone para cada organización.

PUNTUACIÓN

Interpretar una puntuación CVSS

CVSS expresa la severidad mediante una puntuación numérica de 0,0 a 10,0.

De forma general, las puntuaciones pueden asociarse a categorías cualitativas:

0,0 → Ninguna
0,1–3,9 → Baja
4,0–6,9 → Media
7,0–8,9 → Alta
9,0–10,0 → Crítica

Estas categorías ayudan a comunicar la severidad, pero una vulnerabilidad con una puntuación elevada no tiene por qué ser automáticamente la primera que una organización deba corregir.

La prioridad depende también del contexto real del activo afectado.

MÉTRICAS

El vector CVSS

Además de la puntuación numérica, CVSS puede representar las métricas utilizadas mediante una cadena denominada vector.

Conceptualmente:

Vector CVSS
↓
Conjunto de métricas
↓
Características de la vulnerabilidad
↓
Cálculo de severidad

El vector aporta más información que observar únicamente la puntuación final, porque permite conocer qué características han intervenido en la valoración.

Para interpretar un vector concreto debe utilizarse la documentación correspondiente a la versión de CVSS con la que fue calculado.

CONTEXTO

Severidad no es lo mismo que riesgo

Una puntuación de severidad describe características de una vulnerabilidad, pero la prioridad operativa requiere considerar además el entorno donde aparece.

Por ejemplo, pueden influir:

la importancia del activo afectado;
si el sistema está expuesto a Internet;
la función que desempeña;
los datos que procesa;
los controles de seguridad existentes;
la existencia de una corrección;
la posibilidad de aplicar mitigaciones;
la información disponible sobre explotación;
el impacto de una interrupción durante la actualización.

Severidad técnica
+
Exposición
+
Importancia del activo
+
Controles existentes
+
Información disponible=Prioridad contextual

Por ello, ordenar vulnerabilidades únicamente por su puntuación CVSS puede producir una priorización incompleta.

VISIBILIDAD

Inventario de activos

Es difícil gestionar vulnerabilidades sin saber qué sistemas, aplicaciones y componentes existen en el entorno.

Un inventario puede incluir:

sistemas operativos;
servidores y estaciones de trabajo;
aplicaciones;
servicios;
dispositivos de red;
versiones de software;
dependencias;
responsables de los activos;
nivel de criticidad o función.

Activo
↓
Software y versión
↓
Vulnerabilidades conocidas
↓
Evaluación
↓
Acción

Mantener información actualizada sobre los activos facilita determinar qué vulnerabilidades son realmente relevantes para el entorno.

DETECCIÓN

Identificación de vulnerabilidades

Las vulnerabilidades pueden conocerse a través de diferentes fuentes.

avisos de fabricantes;
bases de datos de vulnerabilidades;
herramientas de análisis;
inventarios de dependencias;
revisiones de configuración;
auditorías de seguridad;
equipos internos de seguridad;
fuentes institucionales.

Una detección automática debe validarse dentro del contexto real del sistema. La presencia de una versión o componente puede requerir comprobaciones adicionales antes de concluir que una vulnerabilidad concreta afecta realmente al activo.

GESTIÓN

Gestión y priorización de vulnerabilidades

La gestión de vulnerabilidades es un proceso continuo que permite identificar, evaluar y tratar debilidades de seguridad.

Inventariar
↓
Identificar
↓
Validar
↓
Evaluar
↓
Priorizar
↓
Corregir o mitigar
↓
Verificar
↓
Registrar
↓
Revisar

La priorización permite dedicar primero los recursos a aquellas vulnerabilidades que representan una necesidad más urgente dentro del contexto de la organización.

PRIORIDAD

Qué considerar al priorizar

Una priorización útil combina información técnica con información sobre el entorno.

Entre los criterios que pueden considerarse se encuentran:

severidad de la vulnerabilidad;
criticidad del activo;
exposición del sistema;
existencia de explotación conocida;
disponibilidad de una actualización;
existencia de mitigaciones;
controles compensatorios;
impacto potencial sobre el servicio;
dependencias del sistema;
requisitos internos o regulatorios aplicables.

Vulnerabilidad crítica
+
Sistema no expuesto
+
Controles adicionales
→ evaluar contexto Vulnerabilidad relevante
+
Activo crítico
+
Exposición significativa
→ prioridad mayor

El objetivo es evitar decisiones automáticas basadas únicamente en un número y relacionar cada vulnerabilidad con su contexto real.

TRATAMIENTO

Corrección y mitigación

Una vulnerabilidad puede requerir diferentes medidas según el producto afectado, la disponibilidad de una corrección y las características del entorno.

Algunas posibilidades son:

instalar una actualización de seguridad;
actualizar a una versión corregida;
modificar una configuración;
deshabilitar una función innecesaria;
restringir la exposición del servicio;
aplicar una mitigación temporal;
retirar un componente que ya no puede mantenerse.

Vulnerabilidad identificada
↓
¿Existe corrección?
↓
Aplicar corrección o mitigación adecuada
↓
Verificar el resultado

Las medidas concretas deben basarse en la documentación del fabricante y en la evaluación del entorno.

COMPROBACIÓN

Verificar después de corregir

Aplicar una actualización o modificar una configuración no debería considerarse el final del proceso.

Después del tratamiento conviene comprobar:

que la actualización se instaló correctamente;
que la versión esperada está activa;
que la configuración aplicada es la prevista;
que el servicio continúa funcionando;
que la vulnerabilidad ya no aparece como pendiente;
que no se han introducido efectos no deseados.

Corregir
↓
Verificar
↓
Documentar
↓
Cerrar o mantener seguimiento

VALIDACIÓN

Resultados que requieren validación

Las herramientas automatizadas son útiles para analizar muchos activos, pero sus resultados deben interpretarse correctamente.

Una detección puede requerir revisión cuando:

la versión se ha identificado de forma aproximada;
el fabricante ha aplicado una corrección específica;
la función vulnerable no está habilitada;
el componente no está realmente presente;
la vulnerabilidad no afecta a esa configuración concreta.

Del mismo modo, que una herramienta no detecte una vulnerabilidad no demuestra por sí solo que el sistema carezca de debilidades.

CICLO

Un proceso continuo

La gestión de vulnerabilidades no es una actividad que se realiza una sola vez.

Aparecen nuevas vulnerabilidades, se instalan nuevas aplicaciones, cambian las versiones y se modifican los sistemas.

Inventario
↓
Detección
↓
Evaluación
↓
Tratamiento
↓
Verificación
↓
Seguimiento
↓
Nueva revisión

Mantener este ciclo permite adaptar la gestión a los cambios del entorno y a la aparición de nueva información.

ERRORES FRECUENTES

Qué conviene evitar

considerar CVE y CVSS como si fueran lo mismo;
interpretar un identificador CVE como una puntuación;
priorizar únicamente por puntuación CVSS;
ignorar la criticidad del activo afectado;
no mantener un inventario actualizado;
dar por válidos todos los resultados automáticos sin revisión;
aplicar cambios sin considerar su impacto operativo;
corregir sin verificar posteriormente;
mantener software sin soporte durante periodos innecesarios;
no documentar excepciones o mitigaciones temporales.

EJEMPLO

Ejemplo de evaluación

Supongamos que el inventario identifica una vulnerabilidad conocida en un servicio.

Activo: servidor de aplicación
Vulnerabilidad: identificada mediante CVE
Severidad: alta
Exposición: accesible desde una red limitada
Corrección: actualización disponible
Activo: importante para el servicio Decisión:
evaluar el contexto y planificar la corrección

La puntuación de severidad aporta información relevante, pero la decisión final también considera exposición, importancia del activo, controles existentes y disponibilidad de una solución.

RESUMEN

Ideas fundamentales

Una vulnerabilidad es una debilidad que puede afectar a la seguridad de un activo.
Vulnerabilidad, amenaza y riesgo son conceptos relacionados pero diferentes.
CVE proporciona identificadores comunes para vulnerabilidades divulgadas públicamente.
Un identificador CVE no representa por sí mismo la gravedad de una vulnerabilidad.
CVSS permite expresar características relacionadas con la severidad.
La puntuación CVSS no equivale directamente al riesgo de una organización.
El contexto del activo es esencial para establecer prioridades.
El inventario permite relacionar vulnerabilidades con sistemas realmente presentes.
Los resultados automáticos deben validarse.
Después de corregir una vulnerabilidad debe verificarse el resultado.
La gestión de vulnerabilidades es un proceso continuo.

SIGUE APRENDIENDO

Recursos relacionados

La gestión de vulnerabilidades se relaciona directamente con otros fundamentos de ciberseguridad:

Fundamentos de ciberseguridad — activos, amenazas, riesgos y controles.
Hardening de sistemas — reducción de superficie de ataque y configuración segura.
Seguridad de redes — exposición, segmentación y protección de comunicaciones.
Autenticación y control de acceso — identidades, permisos, MFA y mínimo privilegio.

PARA AMPLIAR

Documentación de referencia

Fuentes oficiales para consultar identificadores, métricas y documentación relacionada con vulnerabilidades.