Cómo priorizar vulnerabilidades: un marco práctico (CVSS, EPSS, KEV)
Los equipos de seguridad no tienen un problema de vulnerabilidades — tienen un problema de priorización. Un solo escaneo empresarial puede devolver cientos de miles de hallazgos, pero solo una fracción mínima representa un riesgo real y a corto plazo. El trabajo ya no es "encontrar vulnerabilidades"; es decidir cuáles de las miles que ya conoces corregir primero.
Esta guía presenta un marco práctico, basado en señales, para priorizar vulnerabilidades por riesgo real en vez de por conteos brutos — usando explotabilidad (EPSS), explotación activa (CISA KEV) y exposición de negocio.
Por qué un CVSS "Crítico" no basta
CVSS (Common Vulnerability Scoring System) mide la severidad teórica de un fallo, no la probabilidad de que llegue a usarse contra ti. En la mayoría de los entornos, más de la mitad de los hallazgos caen en la banda Alta o Crítica, lo que hace que "corregir todas las críticas" sea matemáticamente imposible y operativamente inútil.
La brecha es enorme: solo un pequeño porcentaje de las CVE publicadas se explotan alguna vez en la práctica. Si CVSS es tu única lente, tu equipo gasta sus escasas horas parcheando problemas teóricamente graves que ningún atacante tocará, mientras el puñado que sí se está explotando hoy queda en el mismo montón indiferenciado.
CVSS es una entrada útil. Como estrategia de priorización por sí sola, es pésima.
Las tres señales que de verdad predicen el riesgo
1. Explotabilidad — EPSS
El Exploit Prediction Scoring System (EPSS) asigna a cada CVE una probabilidad —entre 0 y 1— de ser explotada en los próximos 30 días. Es data-driven y se actualiza a diario. Una CVE con EPSS de 0,90 está en una clase de riesgo completamente distinta a una de 0,001, aunque ambas tengan un CVSS de 9,8.
2. Explotación activa — CISA KEV
El catálogo CISA Known Exploited Vulnerabilities (KEV) es la verdad sobre el terreno: lista las CVE que se están explotando ahora mismo. Cualquier entrada de KEV presente en tu parque es innegociable y salta al principio de la cola sin importar su CVSS o EPSS. No hay nada "teórico" en una vulnerabilidad que ya está en las herramientas de los atacantes.
3. Exposición de negocio
La misma CVE no es el mismo riesgo en cada máquina. Un fallo en un servidor crítico expuesto a Internet exige una urgencia distinta al fallo idéntico en una máquina de pruebas interna y aislada sin datos sensibles. El contexto del activo —exposición, criticidad, sensibilidad de datos— es lo que convierte una puntuación genérica en tu riesgo.
Un marco práctico de priorización
Puedes aplicarlo en cinco pasos, a mano o con herramientas:
- Reconcilia. Reúne los hallazgos de todos los scanners (red, agente, cloud, contenedor, SCA) y deduplica a un único inventario de activos y CVE. No puedes priorizar lo que no ves en un solo lugar.
- Tría por explotación activa. Marca todo lo que esté en CISA KEV. Es tu nivel de "deja todo lo demás".
- Añade explotabilidad. Ordena el resto por EPSS para sacar a la superficie las CVE con más probabilidad de ser armadas pronto.
- Pondera por exposición. Multiplica esa probabilidad por el contexto de negocio — primero lo expuesto a Internet, las joyas de la corona y los sistemas de identidad.
- Agrupa por acción de remediación. Colapsa los hallazgos en las acciones que los resuelven (un parche, una actualización, un cambio de configuración). Una sola acción suele cerrar miles de hallazgos en muchos hosts.
El resultado no es un informe de 250.000 filas. Es una lista corta y ordenada de correcciones que reducen el riesgo de forma medible por unidad de esfuerzo.
Combinaciones tóxicas: cuando lo "bajo" se vuelve "crítico"
El riesgo no es aditivo. Un fallo de escalada de privilegios de severidad media y un bug de ejecución de código de severidad baja pueden parecer ignorables por separado — pero encadenados en el mismo host forman una ruta de ataque completa. Estas "combinaciones tóxicas" superan rutinariamente a las críticas individuales que las rodean, y la puntuación pura por CVE nunca las revelará. Una priorización eficaz evalúa las vulnerabilidades en el contexto del host en el que viven, no como ítems aislados.
De la priorización a la remediación
La priorización solo importa si termina en una corrección. La última milla es convertir tu lista ordenada en trabajo que se entrega: agrupa los hallazgos en acciones de remediación, adjunta la evidencia que los ingenieros necesitan y enrútalas directamente a Jira o ServiceNow con el contexto ya incluido. Después mide el cierre y vuelve a priorizar — porque los EPSS y el catálogo KEV cambian a diario, y el ranking de la semana pasada ya está caduco.
Cómo priorIQ.ai lo automatiza
priorIQ.ai se construyó para ejecutar exactamente este marco de forma continua. Reconcilia los hallazgos de Tenable, Qualys, Rapid7, Snyk, Wiz y scanners de cloud en un solo inventario, y puntúa cada grupo con KEV, EPSS, detección de combinaciones tóxicas y exposición de negocio — colapsando 250.000 hallazgos brutos a las pocas cientos de acciones que de verdad mueven la aguja, y orquestando la remediación a través de tu flujo existente de Jira o ServiceNow.
Si te ahogas en la salida de los scanners, solicita una demo y mira tus propios datos priorizados en minutos.
Preguntas frecuentes
¿Es EPSS mejor que CVSS? Responden a preguntas distintas. CVSS describe lo grave que sería un fallo si se explotara; EPSS estima lo probable que es la explotación. Usa CVSS para el contexto de severidad y EPSS (más KEV) para ordenar.
¿Con qué frecuencia debemos re-priorizar? De forma continua, o al menos a diario. Las altas en KEV y los cambios de EPSS pueden mover de la noche a la mañana una CVE de baja prioridad al primer puesto.
¿Dónde encajan las combinaciones tóxicas? Trátalas como ciudadanas de primera clase, a la par de KEV. Una cadena que logra el compromiso total del host debe remediarse aunque ninguna CVE individual parezca alarmante.