Priorización de vulnerabilidades: cómo decidir qué corregir primero

Por qué la gravedad por sí sola no funciona

Lo habitual es ordenar por CVSS y avanzar desde los críticos hacia abajo. Parece objetivo, y falla por tres motivos:

• CVSS mide la gravedad, no el riesgo. Describe lo grave que sería una vulnerabilidad si se explotara. No dice si alguien la está explotando ni si importa en su producto.
• Demasiados elementos de la lista son urgentes. Muchas CVE publicadas obtienen una puntuación alta o crítica, de modo que una cola ordenada por CVSS pone cientos de hallazgos arriba y no ofrece forma de elegir entre ellos.
• La lista no es mejor que el inventario. Un escáner que lee un lockfile indica dependencias de desarrollo que nunca se distribuyen, y se le escapan paquetes que el build descargó fuera del gestor de paquetes. Ambas cosas distorsionan la clasificación antes de que empiece.

La priorización añade las preguntas que faltan: si se está explotando, qué probabilidad hay de que se explote y qué le ocurre a usted si se explota.

Las señales

Señal	Pregunta que responde	Fuente
CVSS	¿Qué gravedad tiene si se explota? Puntuación de 0 a 10.	FIRST (el estándar); la NVD y los proveedores publican puntuaciones
EPSS	¿Qué probabilidad hay de que se explote en los próximos 30 días? Una probabilidad de 0 a 1.	FIRST, actualizado a diario, gratuito
CISA KEV	¿Ya se está explotando en entornos reales?	Catálogo Known Exploited Vulnerabilities de CISA
SSVC	Dados la explotación, el impacto y su misión, ¿qué debe hacer: seguir, atender o actuar?	Árboles de decisión de CERT/CC y CISA
Su contexto	¿Se distribuye la versión vulnerable? ¿Está expuesta? ¿Qué importancia tiene el producto? ¿Hay corrección?	Su inventario, su arquitectura y sus registros de activos

Las señales públicas describen la vulnerabilidad. Solo su contexto describe su riesgo, y es la parte que la mayoría de los equipos obtiene de la fuente menos fiable.

Un método práctico de priorización

La mayoría de los programas acaban con alguna versión de estos niveles. Fije los plazos según lo que pidan su política y sus clientes.

1. Corregir ya: explotación conocida, en software que distribuye. Todo lo que esté en la lista KEV, o con otras pruebas de explotación, y presente en un build publicado. Como referencia, la BOD 26-04 de CISA da a las agencias federales de EE. UU. apenas 3 días para una entrada de KEV en un sistema expuesto públicamente.
2. Corregir después: graves y con probabilidad de explotación. Una puntuación EPSS alta combinada con un CVSS alto o crítico, en un componente distribuido y expuesto. Elija un umbral de EPSS que dé una cola que su equipo pueda vaciar realmente.
3. Corregir de forma rutinaria: todo lo demás que se distribuye. Agrúpelo en actualizaciones periódicas de dependencias en lugar de tratar cada hallazgo como un incidente.
4. Documentar: no afectado. El paquete vulnerable está presente, pero el código vulnerable no se utiliza, o el componente no se distribuye. Registre el razonamiento como declaración VEX, de modo que el mismo hallazgo no vuelva a revisión y los clientes que pregunten puedan ver el motivo.

Después, reclasifique de forma continua. Una vulnerabilidad que estaba en el nivel tres puede pasar al nivel uno de la noche a la mañana cuando se añade a KEV o su puntuación EPSS se dispara.

Las vulnerabilidades que nunca llega a clasificar

Todo método de priorización clasifica los hallazgos que tiene delante. Un paquete vulnerable que el escáner nunca vio no genera ningún hallazgo, de modo que nunca obtiene una puntuación CVSS, una puntuación EPSS ni una coincidencia en KEV. No queda en un puesto bajo. No queda en ningún puesto, y se distribuye de todos modos.

Esto ocurre más a menudo de lo que parece, porque la mayoría de los escáneres deducen lo que hay en su software a partir de archivos: el lockfile, los manifiestos o la salida del build. Todo lo que el build descarga y que ningún lockfile enumera es una dependencia oculta, y a las herramientas basadas en archivos se les escapa:

• Hooks de instalación. Código descargado por los scripts preinstall y postinstall de npm, la vía que utilizó el gusano Shai-Hulud.
• Scripts de build. Por ejemplo, los scripts de build de Rust que descargan código durante el build.
• Imágenes base. La imagen base de un build de contenedor y sus capas del sistema operativo.
• Cachés. Paquetes restaurados desde una caché de CI en lugar de instalarse desde el lockfile.

Escanear la salida después no cierra la brecha. Un binario terminado, sobre todo el código compilado como Rust, deja al escáner adivinando qué entró en él. Y como los builds no son reproducibles por defecto, volver a compilar el mismo commit más adelante no garantiza las mismas dependencias.

Una SBOM registrada durante el build parte del otro extremo. CRACI ejecuta sus jobs de GitHub Actions y ve el tráfico que entra en cada build, de modo que registra cada paquete que el job incorporó realmente, incluidas las dependencias ocultas. Cada SBOM lleva un estado de completitud que indica cuándo algo no se pudo ver. En la práctica, CRACI ha encontrado paquetes vulnerables de los que Snyk y Aikido no informaron, porque a sus escaneos les faltaban esos componentes. Esos son exactamente los hallazgos que un método de priorización nunca tiene ocasión de clasificar.

El contexto: la parte que los escáneres no pueden puntuar por usted

¿Se distribuye realmente la versión vulnerable?

Esta es la pregunta que más ruido elimina. Un framework de pruebas en un lockfile, un paquete fijado en una rama que nunca se publica, una etapa de contenedor que se descarta: nada de eso llega a los clientes. Una SBOM registrada durante el build responde a la pregunta a partir de lo que el build de la versión utilizó realmente, y no de lo que declara el repositorio.

¿Qué versiones la contienen y desde cuándo?

Un hallazgo en un producto que distribuye a clientes, con todas las versiones desde la primavera pasada afectadas, tiene prioridad sobre el mismo hallazgo en una herramienta interna. Conocer el periodo de exposición también le dice qué debe divulgar.

¿Se puede alcanzar el código vulnerable?

El análisis de alcanzabilidad determina si su código puede invocar la función vulnerable de una dependencia. Varias herramientas de SCA lo ofrecen, y es eficaz para empujar los hallazgos inalcanzables hacia abajo en la lista. Trátelo como un dato más: solo ve las rutas de código que el análisis puede seguir, y una función alcanzable no es lo mismo que una función explotable.

¿Está expuesto y hay corrección?

Un servicio expuesto a internet está por encima de un trabajo por lotes en una red privada. Una vulnerabilidad con una versión corregida es más barata de cerrar que una que necesita una mitigación. Ambas cosas cambian el orden, no si se gestiona o no.

Gestión de vulnerabilidades basada en el riesgo

La gestión de vulnerabilidades basada en el riesgo es el nombre a nivel de programa de esa misma idea: clasificar por pruebas de explotación, probabilidad, gravedad y contexto de negocio, medir la rapidez con que se cierran los hallazgos de mayor riesgo y aceptar que los de bajo riesgo puedan seguir abiertos. Las métricas cambian con ello. En lugar del recuento total de vulnerabilidades abiertas, haga un seguimiento de cuántas vulnerabilidades explotadas conocidas hay abiertas en el software distribuido y cuánto tiempo siguen abiertas.

Herramientas de priorización de vulnerabilidades

Tres tipos de herramientas hacen hoy la mayor parte de la clasificación:

• Las plataformas de gestión de vulnerabilidades de infraestructura, como Tenable, Qualys y Rapid7, puntúan hosts, endpoints y activos en la nube con sus propias calificaciones de riesgo, basadas en inteligencia sobre explotación.
• Las herramientas de SCA y de seguridad de aplicaciones, como Snyk, Endor Labs y Semgrep, clasifican los hallazgos de dependencias, varias de ellas con análisis de alcanzabilidad.
• Las herramientas de código abierto, como Grype, que indica datos de EPSS y KEV junto con sus hallazgos, y Dependency-Track, que analiza las SBOM de forma continua.

La comparativa de herramientas de gestión de vulnerabilidades las repasa una por una.

Cómo apoya CRACI la priorización

CRACI empieza donde la clasificación falla con más frecuencia: el inventario. Ejecuta sus jobs de GitHub Actions y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés y las dependencias ocultas que ningún lockfile enumera.

• Hallazgos sobre lo distribuido. Las SBOM monitorizadas se reevalúan de forma continua, y las vistas de organización agregan los hallazgos de todos los builds y repositorios. Cada paquete muestra sus avisos con la gravedad y los paquetes que lo incorporan.
• Periodo de exposición. El historial de builds muestra qué builds anteriores contenían una dependencia vulnerable, directa o transitiva, de modo que usted sabe qué versiones se vieron afectadas y durante cuánto tiempo.
• Triaje y asignación. Los equipos de seguridad hacen el triaje de los hallazgos y envían cada uno al equipo responsable de la corrección. CRACI es compatible con VEX para registrar que una vulnerabilidad no afecta a su producto.
• Controles. Los controles de política pueden bloquear un build por sus hallazgos, incluido un build que contiene una CVE concreta.

CRACI no ofrece análisis de alcanzabilidad. Si esa es la señal que más necesita, elija una de las herramientas de SCA que lo ofrecen. Consulte el seguimiento de vulnerabilidades para ver la funcionalidad completa.

Priorización de vulnerabilidades: preguntas frecuentes

¿Qué es la priorización de vulnerabilidades?

La priorización de vulnerabilidades consiste en decidir qué vulnerabilidades conocidas corregir primero, cuáles pueden esperar y cuáles no le afectan en absoluto. Clasifica los hallazgos según la probabilidad de que se exploten y el daño que eso causaría en su entorno, no solo por su gravedad.

¿Cómo se priorizan las vulnerabilidades?

Parta de un inventario preciso, para clasificar las vulnerabilidades del software que realmente se distribuye. Ponga primero todo lo que esté en la lista Known Exploited Vulnerabilities de CISA y clasifique el resto por probabilidad de explotación (EPSS) y gravedad (CVSS), ajustadas a su contexto: exposición, importancia del producto y existencia de una corrección. Registre las que no le afectan como declaraciones VEX.

¿Basta CVSS para priorizar vulnerabilidades?

No. CVSS mide la gravedad de una vulnerabilidad, no la probabilidad de que se explote ni cuánto le importa a usted. Clasificar solo por CVSS marca como altas o críticas gran parte del backlog, y la mayoría de esas vulnerabilidades nunca se explotan.

¿Qué es la gestión de vulnerabilidades basada en el riesgo?

La gestión de vulnerabilidades basada en el riesgo clasifica y corrige las vulnerabilidades según el riesgo que suponen para su organización, combinando pruebas de explotación, probabilidad, gravedad y contexto de negocio, en lugar de abordarlas por puntuación CVSS o antigüedad.

¿Cuál es la diferencia entre EPSS y KEV?

EPSS es una previsión: la probabilidad estimada de que una CVE se explote en los próximos 30 días. KEV es un registro: el catálogo de CISA de vulnerabilidades con pruebas de explotación en entornos reales. Una entrada de KEV es un hecho; una puntuación EPSS es una probabilidad. Use primero KEV y después EPSS para clasificar todo lo demás.

¿El análisis de alcanzabilidad sustituye a la priorización?

No, es un dato más. La alcanzabilidad comprueba si su código puede invocar la función vulnerable de una dependencia. Elimina los hallazgos que no se pueden activar, pero no dice nada sobre la probabilidad de explotación y solo cubre el código que el análisis puede seguir.