Cuando «crítica» no es tan crítica: por qué repensar la severidad de las vulnerabilidades

La magnitud del ruido

El volumen de vulnerabilidades divulgadas cada año justifica la urgencia de esta conversación. En 2024 se publicaron más de 40.000 CVE nuevos, un aumento del 38% respecto a los aproximadamente 29.000 registrados en 2023. Para finales de 2025, esa cifra había crecido otro 21%, alcanzando 48.185. Eso equivale a más de 100 nuevos identificadores de vulnerabilidades por día. Una proporción considerable de ellos recibe etiquetas de severidad alta o crítica bajo el marco estándar de puntuación base CVSS (el año pasado, esa proporción fue de casi el 40%). Si una organización intentara tratar cada hallazgo CVSS crítico como una emergencia real, agotaría a su personal y su presupuesto tratando de reducir los supuestos riesgos.

Sin embargo, de las decenas de miles de vulnerabilidades publicadas cada año, solo una pequeña fracción llega a ser explotada en el mundo real. Un análisis de los datos de 2024 encontró que aproximadamente el 0,9% de los CVE reportados fueron utilizados activamente por actores de amenazas. Un análisis independiente situó la proporción de CVE empleados en ataques de ransomware o por grupos de amenazas persistentes avanzadas (APT) en torno al 0,2%.

Estas cifras no significan que el resto de las vulnerabilidades sean inofensivas. Sin embargo, sugieren con fuerza que la etiqueta "crítico" se aplica con mucha más frecuencia que la justificable por patrones reales de explotación.

Dónde discrepan las puntuaciones

Si la severidad fuera una medición completamente objetiva, cabría esperar que distintas autoridades, al evaluar la misma vulnerabilidad, llegaran a cifras similares. Pero muchas veces no es así.

Un examen de aproximadamente 120.000 CVE con puntuaciones CVSS v3.0 en el NVD encontró que cerca del 20% de ellos (casi 25.000 entradas) tenían dos puntuaciones: una asignada por el NIST y otra por el fabricante o un CNA externo. De ese subconjunto, el 56% presentaba puntuaciones contradictorias. Es decir, en más de la mitad de los casos en los que tanto el NVD como el fabricante se pronunciaron, no coincidieron en la gravedad del problema.

Tomemos el caso del CVE-2023-21557, una vulnerabilidad en el protocolo LDAP de Windows, que se examina en la fuente citada. Microsoft, la empresa que escribió el código y conoce a fondo los requisitos de explotación, le asignó un 7,5 (alto), mientras que el NVD le asignó un 9,1 (crítico). Esa diferencia de 1,6 puntos no es cosmética. En una organización, una puntuación superior a 9,0 puede activar protocolos de remediación de emergencia, lo que implica sacar ingenieros de otras tareas y alterar los ciclos de lanzamiento. Una puntuación de 7,5, en cambio, podría caer dentro del ciclo regular de remediación mensual. La misma vulnerabilidad provoca dos respuestas muy distintas según el número en el que confíes.

Este tipo de diferencia no es un caso aislado. Las investigaciones han demostrado que las evaluaciones CVSS no son consistentes incluso por la misma persona a lo largo del tiempo. En una encuesta de seguimiento realizada nueve meses después de la evaluación inicial, el 68% de los participantes asignó una calificación de severidad diferente a la misma vulnerabilidad que habían puntuado antes. Esto significa que el propio sistema diseñado para estandarizar la severidad deja espacio para la subjetividad.

Además, un estudio independiente identificó más de 12.800 entradas en el NVD donde vulnerabilidades con descripciones idénticas o semánticamente equivalentes recibieron puntuaciones CVSS significativamente distintas. La inconsistencia no se limitó a casos marginales, sino que abarcó tipos de vulnerabilidades comunes y productos ampliamente conocidos.

La lógica del NVD

Es importante ser justos con las razones detrás de la forma en que el NVD puntúa. El propio NVD explica en su página de métricas de vulnerabilidades que el CVSS, tal como lo utiliza el NVD, es una medida de severidad, no de riesgo. Esa misma página reconoce que, cuando un fabricante o responsable del proyecto se abstiene de proporcionar ciertos detalles, los esfuerzos de enriquecimiento del NVD asignan valores a las métricas CVSS utilizando un enfoque de peor escenario posible. La información excesivamente vaga o no disponible es el motivo del enriquecimiento que se realiza y que produce las diferencias en las puntuaciones. Si, por ejemplo, la fuente no especifica si una vulnerabilidad requiere autenticación, el NVD asumirá que no la requiere, lo cual eleva la puntuación.

Esta política es defendible en lo abstracto. El NVD sirve a una audiencia amplia y diversa, y pecar de cauteloso en un advisory genérico tiene cierta lógica. Pero el efecto es que una puntuación concebida originalmente como una estimación conservadora con la configuración más expuesta posible se convierte en la severidad por defecto que consumen las herramientas automatizadas, los paneles de control y los marcos de cumplimiento, y sobre la cual se toman decisiones.

Daniel Stenberg, el creador y desarrollador principal de cURL, probablemente uno de los componentes de software más usados en el mundo, ha escrito extensamente sobre esta dinámica. En una publicación de 2023 en su blog, describió cómo el proyecto cURL calificó una vulnerabilidad (CVE-2022-42915) como de severidad media, dadas las condiciones muy limitadas bajo las cuales podía ser explotada, mientras el NVD la puntuó con 9,8 (crítica), y así aparece en GitHub. Stenberg señaló en otra publicación que el NVD no le pidió al equipo de cURL aclaraciones ni detalles, simplemente aplicó su propia evaluación. En otro caso, una vulnerabilidad de cURL que involucraba un integer overflow en la opción de línea de comandos --retry-delay (un problema que Stenberg describió como un error de software, pero no un problema de seguridad) fue puntuada inicialmente con 9,8 por el NVD antes de ser rebajada finalmente a 3,3 tras repetidas disputas. Hace un año, en una publicación de blog titulada "CVSS is dead to us", Stenberg habla de un caso más y menciona que cURL ya no utiliza CVSS. Si revisas sus avisos de CVE, muestran alguno de los niveles de severidad asignados por el equipo de seguridad de cURL y no hay nada de CVSS.

Citamos estos ejemplos no para demonizar al NVD, que presta un servicio público esencial, sino para ilustrar un patrón. Cuando la entidad que más sabe sobre un software discrepa de la entidad que lo puntúa para el mundo, y esto ocurre con frecuencia, algo en el sistema merece un examen más detenido.

Los incentivos en juego

¿Por qué persiste este patrón? Hay que considerar los posibles incentivos, sin asumir mala fe.

Para los agregadores como el NVD y el proyecto Vulnrichment de CISA, el mandato es proteger al público en general. Como indica la propia documentación del NVD, cuando los detalles no son claros, la política es asumir el peor escenario. Es un criterio razonable para una base de datos de acceso público, pero favorece las puntuaciones altas.

Para las herramientas de pruebas de seguridad, la estructura de incentivos también puede inclinarse hacia severidades más altas. Una herramienta que reporta menos hallazgos críticos que un competidor corre el riesgo de ser percibida como menos exhaustiva, ya que encontrar más suele equipararse con ser mejor. En lo que respecta a vulnerabilidades conocidas, las herramientas pueden simplemente heredar las puntuaciones base CVSS del NVD o de los avisos de los fabricantes y presentarlas sin ajustarlas según la alcanzabilidad, la explotabilidad o el contexto específico del cliente. Los supuestos conservadores que vienen incorporados en esas puntuaciones se transmiten sin cuestionamiento, y el panel de la herramienta termina reforzando la misma inflación que, en principio, podría ayudar a corregir.

Para los fabricantes de software que actúan como CNA, el panorama es más complejo. Por un lado, un fabricante que califique sistemáticamente sus propias vulnerabilidades como bajas puede enfrentar acusaciones de minimizar los problemas de seguridad. Por otro, un fabricante que lo califique todo como crítico puede alarmar a sus clientes.

Para los investigadores de seguridad independientes, los CVE tienen valor profesional. Un hallazgo de severidad crítica atrae más atención y puede traducirse en pagos por programas de bug bounty o en progreso profesional. El investigador Florian Hantke puso esto a prueba directamente. Buscó patrones de inyección SQL en GitHub, encontró una aplicación de exámenes en línea cuyo repositorio no había sido actualizado en tres años y cuyo README indicaba que estaba esencialmente abandonada, la explotó en minutos y envió una solicitud de CVE. Y fue aceptada. Una búsqueda en Shodan no había revelado ninguna instancia del software accesible públicamente, sin embargo, la vulnerabilidad fue publicada en el NVD y, como escribió Hantke, calificada con una puntuación alta. Su conclusión fue que necesitamos recalibrar cómo percibimos y valoramos los CVE.

Una mejor pregunta que "¿qué tan grave podría ser?"

La puntuación base CVSS responde a una pregunta específica: en un entorno genérico y en el peor escenario, ¿cuánto daño podría causar esta vulnerabilidad si fuera explotada? Es una pregunta válida. Pero no es la pregunta que la mayoría de los equipos de seguridad necesitan responder a diario. La pregunta más útil es qué tan probable es que esta vulnerabilidad sea explotada en nuestro entorno, y cuál sería el impacto en nuestro contexto específico.

Dos marcos han surgido para ayudar a responder esa pregunta con mayor precisión.

EPSS (Exploit Prediction Scoring System), mantenido por FIRST, utiliza machine learning entrenado con datos reales de explotación para estimar la probabilidad de que un CVE determinado sea explotado en los próximos 30 días. EPSS produce una puntuación entre 0 y 1 (0% a 100%). Resulta que la mayoría de las vulnerabilidades (incluso aquellas con puntuaciones CVSS altas) tienen puntuaciones EPSS muy bajas. Según los propios datos de rendimiento de FIRST, una estrategia de remediar todos los CVE con puntuación CVSS de 7 o superior arroja una eficiencia de aproximadamente el 4%; es decir, solo unas 4 de cada 100 vulnerabilidades remediadas bajo esa política serían realmente explotadas en los 30 días siguientes. El artículo de investigación original de EPSS también cita una investigación previa según la cual apenas el 1,4% de las vulnerabilidades publicadas han sido explotadas en el mundo real. Fluid Attacks ha integrado EPSS en su plataforma precisamente para ayudar a los equipos a concentrarse en esa pequeña fracción.

SSVC (Stakeholder-Specific Vulnerability Categorization), desarrollado por el Software Engineering Institute de Carnegie Mellon University en colaboración con CISA, adopta un enfoque diferente. En lugar de producir una puntuación numérica, SSVC utiliza árboles de decisión que tienen en cuenta el estado actual de explotación, la criticidad de la misión del activo afectado y la prevalencia del componente vulnerable. El resultado es una recomendación orientada a la acción (track, attend o act) en lugar de un número que puede o no corresponderse con una respuesta del mundo real.

Ni EPSS ni SSVC reemplazan a CVSS. Lo complementan añadiendo dimensiones que representan el riesgo.

Qué significa para las organizaciones que desarrollan software

Si tu equipo desarrolla aplicaciones, lo más probable es que esté consumiendo puntuaciones CVSS de múltiples fuentes: las herramientas SAST, los escáneres SCA, tu pipeline de escaneo de contenedores, el propio NVD. Las discrepancias descritas en este artículo no son un problema ajeno, sino que llegan directamente a tus paneles de control y a las tareas pendientes de tus sprints.

Algunos principios pueden ayudar a filtrar el ruido:

• Entiende cómo las herramientas califican las vulnerabilidades: Las herramientas no puntúan los hallazgos de la misma forma. Algunas heredan las puntuaciones base CVSS directamente del NVD, otras aplican su propia lógica de severidad, otras permiten hacer ajustes según factores ambientales. Saber qué enfoque usan tus herramientas, y de dónde provienen sus puntuaciones, te ayuda a interpretar correctamente una etiqueta de "crítica" en vez de reaccionar de forma automática.

• Verifica antes de escalar: Una etiqueta de "crítica" sobre un secreto embebido en el código significa muy poco si nadie ha confirmado si la credencial está activa. Esa etiqueta sobre una vulnerabilidad de biblioteca significa muy poco si la función vulnerable nunca se invoca en tu código. Los equipos que manejan bien la severidad invierten en verificación, es decir, comprueban si los hallazgos son alcanzables, funcionales y explotables en contexto antes de tratarlos como emergencias.

• Usa múltiples señales: CVSS te habla del impacto potencial, EPSS te habla de la probabilidad, el catálogo KEV de CISA te dice qué ya está siendo explotado. Depender de una sola de estas fuentes puede crear puntos ciegos.

• Documenta tu razonamiento: Si decides bajar la prioridad de un hallazgo que tiene una puntuación CVSS crítica porque el EPSS está cerca de cero y el componente no es alcanzable, documenta esa decisión. Regulaciones como la NIS2 en Europa y las normas de divulgación de ciberseguridad de la SEC ponen el énfasis en procesos demostrados de gestión de riesgos, no en la ausencia de vulnerabilidades etiquetadas como críticas.

• Ten cuidado con la fatiga de alertas: Los equipos que están constantemente respondiendo a hallazgos que resultan no tener impacto real terminan por dejar de prestar atención, y es entonces cuando una vulnerabilidad genuinamente peligrosa se les escapa. Ya hemos escrito sobre este problema antes.

Queremos ser claros respecto al espíritu de este artículo. El NVD, CISA, FIRST, el ecosistema de CNAs, las soluciones de pruebas de seguridad y la comunidad de investigación en seguridad cumplen roles esenciales para hacer el software más seguro. La intención aquí no es desacreditarlos, sino reconocer que la calificación de severidad, tal como se practica hoy, tiene limitaciones que los equipos de seguridad deben comprender y tener en cuenta.

La inflación de severidad no es producto de la incompetencia ni de la mala intención. Es la consecuencia natural de un sistema en el que distintos actores, cada uno actuando racionalmente dentro de su propia estructura de incentivos, producen o entregan números que no siempre sirven a quienes deben actuar en función de ellos. Reconocerlo es el primer paso para tomar mejores decisiones.

El segundo paso es complementar CVSS con contexto: datos reales de explotación, criticidad de los activos, análisis de alcanzabilidad y juicio profesional. Los desarrolladores de herramientas, por su parte, pueden contribuir apostando por la exactitud. En lugar de retransmitir una puntuación base CVSS tal cual viene de la fuente original, una herramienta puede intentar verificar si la vulnerabilidad es alcanzable en el código del cliente, si las condiciones para la explotación realmente existen y si el componente afectado está expuesto. Esto es más difícil y más costoso que simplemente pasar un número, pero es también lo que separa un hallazgo útil del ruido. En Fluid Attacks, esta es la filosofía detrás de nuestro enfoque de puntuación. Preferimos decirte que un secreto expuesto tiene severidad baja porque no hemos confirmado el riesgo que implica, en lugar de etiquetarlo todo como crítico y dejarte la tarea de filtrar el ruido.