KEV no incluye toda vulnerabilidad explotable: incluye aquellas con explotación confirmada y publicada. Es un catálogo conservador y explícitamente declarado por CISA. Una vulnerabilidad sin entrada en KEV puede estar siendo explotada sin que CISA la haya registrado todavía.
Qué es KEV
KEV (Known Exploited Vulnerabilities) es el catálogo público que mantiene CISA (la agencia federal de ciberseguridad de Estados Unidos) con las vulnerabilidades cuya explotación en el mundo real ha sido confirmada. A diferencia de la base de datos CVE, que recoge todas las vulnerabilidades publicadas con independencia de su impacto operativo, KEV incluye sólo aquellas que están siendo o han sido usadas en ataques observables. El catálogo nace en 2021 con una directiva operativa para agencias federales estadounidenses, pero hoy se utiliza como referencia internacional de priorización por cualquier organización seria que gestione vulnerabilidades, porque responde a una pregunta muy concreta: ¿esto se está usando hoy contra alguien?
Por qué importa
Un equipo de seguridad típico tiene miles de hallazgos abiertos en cualquier momento dado. Sin un criterio de prioridad útil, esa cola se gestiona por CVSS y se acaba dedicando capacidad a parchear riesgos teóricos mientras una vulnerabilidad media está siendo explotada activamente contra el sector. KEV es la lista que indica "esto ya está pasando" y, por tanto, debe figurar en cualquier política de remediación como prioridad inmediata, por encima de los SLAs habituales. Para marcos como NIS2, DORA o ENS que exigen priorización basada en riesgo, KEV es además una de las pruebas más sólidas de que esa priorización no es teórica sino que sigue evidencia pública.
Puntos clave
Cada entrada de KEV trae fecha de inclusión, breve descripción técnica y, en la mayoría de casos, una fecha límite recomendada de remediación. Esa fecha es vinculante para agencias federales estadounidenses; para el resto, es una buena referencia de urgencia.
KEV se actualiza con frecuencia y no en un calendario fijo. Las plataformas de gestión de vulnerabilidades deben consultarlo al menos a diario para enriquecer sus hallazgos: una CVE puede pasar de "media" a "tratamiento urgente" en cuestión de horas cuando entra en el catálogo.
Combinado con EPSS, KEV produce una regla operativa muy efectiva: "todo lo que esté en KEV se trata como urgencia; todo lo que tenga EPSS por encima de 0,5 se prioriza; el resto sigue SLA habitual". Esa regla, mantenida en política, suele recortar a menos de la mitad la cola de hallazgos críticos.
KEV es especialmente útil para conversaciones con dirección y auditoría. Es público, está mantenido por una agencia reconocida y traduce "tengo cinco mil CVEs abiertos" a "tengo seis CVEs en KEV sin parchear", una métrica con la que cualquier comité puede decidir.
Conviene combinar KEV con la inteligencia de amenazas propia del sector. KEV es global; un buen programa añade fuentes específicas (CCN-CERT en España, ENISA en la UE, listas privadas) que pueden adelantarse a la inclusión oficial cuando el ataque afecta a un país o industria concretos.
Ejemplo: uso de KEV en una política de remediación
Una organización con un parque heterogéneo (entornos cloud, infraestructura on-premise, varios proveedores SaaS) escribe su política de gestión de vulnerabilidades con tres niveles. Nivel 1: cualquier CVE que aparezca en KEV obliga a remediación o mitigación compensatoria en 72 horas, con notificación al CISO y al responsable del activo. Nivel 2: cualquier CVE con EPSS por encima de 0,5 entra en cola acelerada de 7 días. Nivel 3: el resto sigue el SLA habitual por CVSS y criticidad del activo.
El primer día tras publicar la política, el equipo detecta dos servidores expuestos a internet afectados por una CVE recién incluida en KEV. Se aplica mitigación compensatoria (regla en el WAF más restricción del puerto) en menos de 24 horas y se programa el parche definitivo dentro del plazo. La métrica que el equipo presenta al comité es sencilla: "cero vulnerabilidades en KEV sin contención"; el comité la entiende sin necesidad de traducción técnica. La misma evidencia (entradas en KEV cubiertas y plazos cumplidos) se aprovecha en la siguiente auditoría como prueba de priorización basada en riesgo.
Errores habituales
- Tratar KEV como una lista completa de amenazas reales. Una vulnerabilidad puede estar siendo explotada activamente sin haber entrado todavía en KEV. La inclusión es una señal fuerte de urgencia, pero la ausencia no significa seguridad.
- Ignorar las fechas límite recomendadas. CISA publica una fecha de remediación con cada entrada precisamente porque entiende la urgencia del riesgo confirmado. Tratar esa fecha como orientativa anula el principal valor del catálogo.
- Esperar a la aparición en KEV antes de actuar. Para vulnerabilidades con EPSS alto o exploit público conocido, esperar a que CISA confirme la explotación equivale a entregar ventaja al atacante.
- Centralizar la decisión sólo en el equipo de seguridad. Las entradas de KEV deben dispararse como tickets automatizados a los propietarios de activos (TI, desarrollo, proveedor SaaS) con plazo escrito y escalado claro si no se cumple.
- No mapear KEV a marcos regulatorios. Cuando se traduce 'CVEs en KEV pendientes' a 'controles A.8.8 de ISO 27001 con incumplimiento', la métrica viaja sola por la organización y se trata con el peso que merece.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Una vulnerabilidad nunca incluida en KEV es segura de no parchear?
No. KEV es un catálogo conservador que sólo incluye vulnerabilidades con explotación confirmada y publicada por CISA. Muchas vulnerabilidades se explotan en silencio durante semanas antes de aparecer en el catálogo, y otras se explotan en regiones concretas sin llegar nunca a entrar. KEV es una señal fuerte de prioridad inmediata; la ausencia no es prueba de seguridad.
¿Cómo se integra KEV en una herramienta de gestión de vulnerabilidades?
Las plataformas modernas consumen automáticamente el feed público de KEV y enriquecen cada hallazgo con una marca booleana ('en KEV') y la fecha de remediación recomendada. Si la organización aún consume CVE plano sin enriquecimiento, lo prioritario es activar la integración o el script equivalente: el feed es público, abierto y se actualiza a diario.
¿Tiene sentido aplicar KEV fuera de Estados Unidos?
Sí. Aunque KEV nace como obligación operativa para agencias federales estadounidenses, las vulnerabilidades explotadas no respetan fronteras. Cualquier organización fuera de Estados Unidos puede usar KEV como referencia de urgencia operativa, normalmente combinada con el feed de su CERT nacional (CCN-CERT en España, ENISA en la UE).
¿KEV reemplaza a la inteligencia de amenazas comercial?
No, son distintos niveles. KEV es un catálogo oficial, conservador y centrado en CVEs concretas con explotación confirmada. La inteligencia comercial añade actores, campañas, TTPs y telemetría privada que pueden adelantarse a la inclusión en KEV. Un programa maduro usa los dos: KEV como referencia indiscutible y CTI como anticipación.