Cómo priorizar vulnerabilidades: guía práctica con CISA KEV, EPSS, SSVC y contexto del negocio

9 de octubre de 2026 · Actualizada el 11 de octubre de 2026 · Lectura estimada: 14 minutos

Una lista ordenada solo por CVSS puede poner arriba una vulnerabilidad técnicamente crítica que no existe en el entorno y dejar abajo otra menos severa que ya está siendo explotada en un servicio expuesto. La decisión correcta no sale de un único puntaje: combina presencia comprobada, explotación conocida, probabilidad de explotación, alcance técnico, exposición, impacto para el negocio y controles disponibles.

Esta guía propone un método breve y auditable: validar, enriquecer, decidir, remediar y verificar. Usa CISA KEV para reconocer explotación confirmada, EPSS para estimar la probabilidad de explotación durante los próximos 30 días, SSVC para estructurar la decisión y CVSS para describir severidad técnica. El resultado es una cola de trabajo explicable, no una fórmula automática.

Hechos verificados. FIRST define CVSS Base como una medida de severidad, no de riesgo. EPSS estima la probabilidad de explotación en los próximos 30 días, cambia diariamente y no conoce el contexto de cada organización. CISA mantiene el catálogo KEV con vulnerabilidades que cuentan con evidencia de explotación en el mundo real y ofrece SSVC para categorizarlas como Track, Track*, Attend o Act. NIST CSF 2.0 plantea usar amenazas, vulnerabilidades, probabilidades e impactos para determinar y priorizar el riesgo. FIRST, CVSS v4.0 · FIRST, EPSS · CISA, KEV · CERT/CC, SSVC y adaptación CISA · NIST CSF 2.0

Recomendación editorial. Dar prioridad máxima a una vulnerabilidad presente, alcanzable y explotada activamente; después, ordenar el resto con EPSS, exposición, criticidad del activo, consecuencia técnica y capacidad de mitigación. Registrar la evidencia y la fecha de cada señal.

Inferencia. Para una organización pequeña o mediana, un flujo reproducible de seis preguntas suele producir mejores decisiones que intentar construir de inmediato un puntaje compuesto complejo. La calidad del inventario y de la validación local pesa más que la precisión aparente de una fórmula.

• Responsables de seguridad, TI, infraestructura y continuidad.
• Equipos de AppSec, DevSecOps, cloud y respuesta a incidentes.
• Dueños de producto, proveedores administrados y comités de riesgo que deben justificar prioridades.
• Pymes que reciben más alertas de vulnerabilidades de las que pueden corregir en cada ciclo.

La guía sirve para infraestructura, aplicaciones, dependencias, dispositivos y servicios cloud. No reemplaza instrucciones del fabricante, análisis forense, pruebas de compatibilidad ni obligaciones regulatorias o contractuales aplicables.

Ante una vulnerabilidad nueva, responder y documentar estas seis preguntas:

1. ¿Está presente? Confirmar producto, versión, componente y activo afectados. Un resultado de escáner sin validación todavía es una hipótesis.
2. ¿Hay explotación confirmada? Revisar CISA KEV, aviso del proveedor y fuentes de respuesta acreditadas. KEV tiene precedencia sobre una probabilidad EPSS baja.
3. ¿Es alcanzable? Determinar si el atacante puede llegar al componente y cumplir las precondiciones: Internet, red interna, autenticación, privilegios, interacción del usuario o ruta desde otro sistema.
4. ¿Qué probabilidad tiene? Registrar EPSS con fecha, probabilidad y percentil. Usarlo como señal dinámica, no como sentencia.
5. ¿Qué se puede perder? Evaluar identidad, datos, privilegios, continuidad, seguridad física, clientes y capacidad de propagación. Incorporar criticidad y propietario del activo.
6. ¿Qué respuesta es viable? Parchear, actualizar, deshabilitar una función, aislar, bloquear una ruta, reforzar detección o aceptar temporalmente el riesgo con plazo y autoridad definidos.

Si existe compromiso activo o indicios de explotación local, deja de ser solo gestión de vulnerabilidades: activa respuesta a incidentes, preserva evidencia y coordina contención.

FIRST advierte que no se debe multiplicar EPSS por CVSS: tienen escalas y propósitos diferentes. También aclara que una probabilidad EPSS baja no equivale a seguridad y que KEV, al reflejar explotación confirmada, debe tener precedencia para las vulnerabilidades afectadas. FIRST, EPSS FAQ · FIRST, Using EPSS

Partir por el activo, no por el titular de la alerta. Vincular el CVE con una versión observada, un paquete, una imagen, un servicio o una dependencia efectivamente desplegada.

Evidencia útil:

• inventario o SBOM con fecha;
• versión obtenida desde el sistema o artefacto desplegado;
• resultado del escáner y regla que produjo la detección;
• configuración que activa o desactiva la función vulnerable;
• entorno afectado: producción, preproducción, desarrollo o respaldo.

Si el componente no está presente, cerrar o marcar “no afectado” con evidencia y criterio de reapertura. Si no se puede comprobar, mantener “presencia pendiente”; no convertir ausencia de datos en ausencia de riesgo.

Consultar la ficha del fabricante, CISA KEV, EPSS y, cuando aporte valor, la información de CISA Vulnrichment. Registrar fuente, fecha y valor, porque la amenaza cambia. EPSS publica puntajes diarios; CISA agrega a CVE públicos campos de SSVC y datos de KEV para facilitar la priorización. FIRST, acceso a datos EPSS · CISA, Vulnrichment

No confundir:

• PoC público con explotación confirmada;
• percentil EPSS con probabilidad: estar en el percentil 90 significa puntuar por encima del 90 % de los CVE evaluados, no tener 90 % de probabilidad;
• ausencia en KEV con ausencia de explotación;
• puntaje viejo con estado actual de la amenaza.

Revisar la ruta real hacia el componente:

• exposición directa a Internet, VPN, API, correo o interfaz administrativa;
• controles de autenticación y nivel de privilegio requerido;
• segmentación, WAF, EDR, allowlists u otras barreras;
• posibilidad de movimiento lateral o salto de confianza;
• datos y procesos dependientes;
• capacidad de recuperación y ventana operacional.

Un control compensatorio reduce el riesgo solo si está desplegado, cubre la ruta de ataque y puede verificarse. La mera existencia de una herramienta en el inventario no demuestra protección.

La adaptación CISA de SSVC descrita aquí utiliza cuatro resultados. SSVC admite distintos modelos según el actor; estos nombres no son universales para todos ellos. La siguiente tabla es una lectura operativa sugerida y no reemplaza el recorrido del árbol:

Esta adaptación considera explotación, impacto técnico, automatización, impacto en la misión y bienestar público. Para asignar una categoría, elegir el modelo y su versión, registrar la evidencia de cada factor y conservar el recorrido completo del árbol. La documentación primaria de CERT/CC explica la personalización CISA; su calculadora Dryad documenta estos resultados como prototipo de apoyo, no como certificación ni SLA obligatorio. CERT/CC, adaptación CISA · CERT/CC, calculadora y decisiones Dryad

Elegir una respuesta explícita:

• actualizar o parchear;
• retirar o reemplazar el componente;
• cambiar configuración o deshabilitar la función;
• aislar el activo o bloquear la ruta de ataque;
• añadir detecciones temporales y monitoreo;
• aceptar el riesgo por plazo limitado, con propietario, fundamento y vencimiento.

Antes del cambio, verificar respaldo, dependencia, prueba y plan de reversa. Después, comprobar versión, configuración, exposición y salud del servicio. Repetir el escaneo no basta si el detector no observa el componente real o conserva datos en caché.

Recomendación editorial. Para vulnerabilidades explotadas, corregir el componente no demuestra que el activo esté libre de compromiso. Evaluar indicios locales y, si corresponde, activar respuesta a incidentes; coordinar la contención con la preservación de registros. NIST CSF 2.0 incluye el análisis de incidentes y la conservación de integridad y procedencia de los datos de investigación (RS.AN-03, RS.AN-06 y RS.AN-07). Se usa como marco técnico, sin convertirlo en una obligación legal general para Chile. NIST CSF 2.0

Los siguientes plazos son una recomendación operativa, no un estándar universal ni un requisito legal. Deben ajustarse según riesgo aceptado, ventanas de cambio, seguridad del servicio y obligaciones contractuales.

No usar un umbral EPSS fijo para todas las organizaciones. FIRST señala que los umbrales deben localizarse según capacidad, tolerancia y distribución de la cartera. Una alternativa es medir qué percentil puede absorber el equipo y validar si ese corte captura activos realmente expuestos. FIRST, Using EPSS

Caso A, hipotético: CVSS 9,8; producto listado en el inventario histórico, pero la versión afectada no está desplegada y la función vulnerable está deshabilitada. No aparece en KEV. La prioridad correcta no es “parche crítico inmediato”: primero se conserva la evidencia de no afectación, se corrige el inventario y se programa una verificación.

Caso B, hipotético: CVSS 7,5; componente presente en una puerta de acceso remoto, alcanzable desde Internet, incluido en KEV y con consecuencia alta para un servicio crítico, confirmada por su propietario. Según la tabla interna de este ejemplo corresponde proponer P0: contener o mitigar, buscar indicios de explotación y remediar con urgencia. P0 no equivale automáticamente a Act. El caso no aporta todos los factores del árbol SSVC, por lo que no asigna una categoría SSVC: antes deben registrarse modelo y versión, estado de explotación, impacto técnico, automatización, misión y bienestar público, junto con el recorrido y su evidencia.

Inferencia: el contraste muestra por qué la severidad técnica sigue siendo importante, pero no puede sustituir presencia, amenaza y contexto. La segunda vulnerabilidad puede merecer recursos antes que la primera.

Métricas útiles: porcentaje de hallazgos con presencia validada, tiempo hasta asignación de propietario, tiempo hasta mitigación de KEV alcanzables, excepciones vencidas, porcentaje de cierres con verificación y vulnerabilidades reabiertas. Evitar una métrica única de “cantidad de CVE cerrados”, porque puede premiar volumen de bajo impacto.

• El activo y la versión fueron observados; no se infirieron solo desde una lista antigua.
• Se registraron CVSS con vector y versión, KEV y EPSS con fecha.
• Probabilidad EPSS y percentil están en campos separados.
• Se documentó la ruta de ataque, incluida autenticación y exposición.
• El dueño del servicio confirmó criticidad, datos y ventana de cambio.
• Los controles compensatorios fueron probados en la ruta relevante.
• La decisión distingue hecho, supuesto e información pendiente.
• Una vulnerabilidad explotada activó evaluación de posible compromiso.
• El cambio tuvo validación técnica y de servicio, además de plan de reversa.
• La excepción, si existe, tiene autoridad, fundamento, vencimiento y monitoreo.
• El cierre contiene evidencia y una fecha de reevaluación.

• Ordenar solo por CVSS. CVSS Base mide severidad, no riesgo local. Complementarlo con amenaza y ambiente. FIRST, CVSS v4.0
• Multiplicar CVSS por EPSS. Produce una cifra difícil de interpretar y no recomendada por FIRST. Mantener las señales separadas y explicar la decisión. FIRST, Using EPSS
• Usar EPSS bajo como permiso para ignorar. La predicción no incluye impacto ni contexto local y cambia diariamente.
• Asumir que no estar en KEV significa no explotada. KEV es una señal positiva fuerte, no un inventario exhaustivo de toda actividad maliciosa.
• Parchear una vulnerabilidad explotada sin buscar compromiso. La actualización puede eliminar el vector, pero no una persistencia ya instalada.
• Automatizar el cierre. Un escáner puede quedar desactualizado, no ver una dependencia o no conocer la configuración efectiva.
• Aceptar riesgo sin vencimiento. Toda excepción debe caducar y volver a la cola con nueva evidencia.
• Confundir guía técnica con obligación legal. Los plazos propuestos aquí son internos y deben adaptarse a obligaciones efectivamente aplicables, contratos, criticidad y capacidad operacional.

1. FIRST, CVSS v4.0 User Guide: CVSS Base mide severidad, no riesgo; uso de métricas Threat y Environmental. Consultada el 11 de octubre de 2026.
2. FIRST, EPSS: definición y horizonte de 30 días. Consultada el 11 de octubre de 2026.
3. FIRST, EPSS FAQ y Using EPSS: probabilidad versus percentil, actualización diaria, límites, relación con KEV y umbrales locales. Consultadas el 11 de octubre de 2026.
4. CISA, Known Exploited Vulnerabilities Catalog: catálogo basado en evidencia de explotación conocida. Consultada el 11 de octubre de 2026.
5. CERT/CC, adaptación CISA de SSVC y Dryad: calculadora y decisiones: personalización del modelo y explicación de Track, Track*, Attend y Act. Dryad se presenta como prototipo de apoyo. Consultadas el 11 de octubre de 2026.
6. CISA, Vulnrichment: enriquecimiento público de CVE con puntos de decisión SSVC y KEV. Consultada el 11 de octubre de 2026.
7. NIST Cybersecurity Framework 2.0: amenazas, vulnerabilidades, probabilidades e impactos como entradas de priorización de riesgo. Consultada el 11 de octubre de 2026.

El archivo público de guías revisado al 9 de octubre de 2026 contiene piezas sobre seguridad de agentes de IA y preparación ante la Ley Marco de Ciberseguridad; además, la guía publicada el 2 de octubre de 2026 aborda las primeras 24 horas de respuesta a incidentes para pymes. No se encontró una guía publicada dedicada a priorización de vulnerabilidades con KEV, EPSS, SSVC y contexto local. El tema complementa las alertas diarias de CVE sin repetirlas.

Actualización del 11 de octubre de 2026: se corrigió la separación entre P0 interno y decisión SSVC, se actualizaron los enlaces de FIRST y se revisaron las fuentes primarias citadas. La referencia no corroborada a una directiva se retiró; la recomendación sobre investigación y evidencia se respalda en NIST CSF 2.0.