KEV: El Catálogo de CISA que Importa Más que el CVSS

Qué es el catálogo KEV

El catálogo KEV (Known Exploited Vulnerabilities) de CISA es, en su esencia, una lista de vulnerabilidades que han sido explotadas en el mundo real. No es una puntuación. No es una predicción. No es una estimación de severidad. Es una confirmación factual: alguien ha usado esta vulnerabilidad para comprometer sistemas reales.

CISA (Cybersecurity and Infrastructure Security Agency), la agencia de ciberseguridad del gobierno federal de Estados Unidos, lanzó el KEV en noviembre de 2021 como parte de la Binding Operational Directive 22-01. La directiva estableció una obligación legal para las agencias federales civiles: remediar las vulnerabilidades del KEV dentro de plazos establecidos o enfrentar consecuencias regulatorias.

El catálogo acumula más de 1.200 CVEs (a mayo de 2026) y sigue creciendo. CISA añade nuevas entradas regularmente, a veces una al día, a veces ocho de golpe. Cada adición significa que CISA ha recibido evidencia creíble de que esa vulnerabilidad está siendo explotada activamente.

Por qué KEV importa más que el CVSS para priorizar

La diferencia fundamental entre CVSS y KEV es la pregunta que responden.

CVSS pregunta: "¿Qué tan grave podría ser esta vulnerabilidad si se explotara?"

KEV responde: "Esta vulnerabilidad está siendo explotada. Ahora."

Para un equipo de operaciones de seguridad con miles de vulnerabilidades pendientes y recursos limitados, la segunda pregunta es incomparablemente más útil. Un CVSS 10.0 teórico que nadie está explotando puede esperar al próximo ciclo de parcheo. Un CVSS 7.5 que aparece en el KEV necesita acción inmediata.

Los números lo ilustran. En 2025, se publicaron más de 48.000 CVEs. Más de 15.000 recibieron una puntuación CVSS de 7.0 o superior (High o Critical). Pero solo unas pocas cientos se añadieron al KEV durante ese año. La diferencia entre 15.000 "potencialmente graves" y unas cientos "confirmadas como explotadas" es la diferencia entre parálisis por exceso de alertas y priorización efectiva.

BOD 22-01: la directiva que creó el KEV

La Binding Operational Directive 22-01, titulada "Reducing the Significant Risk of Known Exploited Vulnerabilities", estableció el marco legal y operacional del KEV. Sus elementos clave:

Alcance legal

BOD 22-01 es vinculante para todas las agencias del Federal Civilian Executive Branch (FCEB). Esto incluye departamentos como Homeland Security, Health and Human Services, Commerce, Energy, y decenas de agencias y subagencias federales. No incluye al Departamento de Defensa (que tiene sus propias directivas), ni al poder legislativo o judicial.

Plazos de remediación

La directiva establece plazos concretos para remediar cada vulnerabilidad del KEV:

• Vulnerabilidades añadidas al catálogo con CVE de 2021 o posterior: remediación en 2 semanas.
• Vulnerabilidades con CVE anterior a 2021: remediación en 6 meses.
• CISA puede establecer plazos específicos por vulnerabilidad cuando la urgencia lo requiere.

Definición de "remediar"

Remediar no significa exclusivamente aplicar un parche. Las acciones aceptables incluyen: aplicar el parche del fabricante, aplicar la mitigación documentada por el fabricante, o desactivar/desinstalar el componente afectado si no es esencial. Lo que no es aceptable: ignorar la vulnerabilidad, aceptar el riesgo sin mitigación, o depender exclusivamente de controles compensatorios.

Reporting

Las agencias deben reportar su estado de cumplimiento a CISA. Las vulnerabilidades no remediadas dentro del plazo generan hallazgos en auditorías de ciberseguridad federales.

Criterios de inclusión

No cualquier vulnerabilidad entra en el KEV. CISA aplica tres criterios estrictos que hacen del catálogo una fuente confiable.

Criterio 1: CVE ID asignado

La vulnerabilidad debe tener un identificador CVE válido asignado por una CNA (CVE Numbering Authority). Esto excluye vulnerabilidades reportadas informalmente, bugs sin advisory formal, o problemas de configuración que no tienen CVE.

Criterio 2: Evidencia de explotación activa

Este es el criterio diferenciador. CISA requiere evidencia confiable de que la vulnerabilidad ha sido explotada en ataques reales contra sistemas de producción. No basta con:

• La existencia de un PoC (Proof of Concept) público.
• Un score CVSS alto.
• Un score EPSS alto (alta probabilidad de explotación futura).
• La mención en un reporte de threat intelligence sin confirmación independiente.

Las fuentes de evidencia incluyen: reportes de incidentes de agencias federales, confirmación por parte de vendors de seguridad (Google TAG, Microsoft Threat Intelligence, Mandiant, CrowdStrike), reportes de CERTs nacionales, y análisis forenses que vinculan la vulnerabilidad con intrusiones documentadas.

Criterio 3: Acción de remediación clara

Debe existir una instrucción concreta y ejecutable para remediar la vulnerabilidad. Generalmente es un parche del fabricante o una mitigación documentada. Si el fabricante no ha publicado parche ni mitigación, la vulnerabilidad no entra en el KEV aunque esté siendo explotada, porque la directiva no puede obligar a remediar algo para lo que no existe remediación.

Este tercer criterio es una de las razones por las que el KEV es conservador. Hay vulnerabilidades explotadas activamente que no están en el catálogo porque no cumplen todos los criterios.

Estadísticas del KEV

Los datos del catálogo KEV revelan patrones significativos sobre qué vulnerabilidades son explotadas en la práctica.

Volumen y crecimiento

El catálogo se lanzó en noviembre de 2021 con un lote inicial de aproximadamente 300 vulnerabilidades. A mayo de 2026, contiene más de 1.200 entradas. La cadencia de adición se ha intensificado: CISA publica actualizaciones con mayor frecuencia y con más vulnerabilidades por actualización que en los primeros años.

Vendors más afectados

Los vendors con más CVEs en el KEV son, consistentemente:

Microsoft lidera por un margen amplio. Windows, Exchange, Office, Edge, y los productos de servidor (Active Directory, IIS, SQL Server) representan la mayor concentración de vulnerabilidades explotadas. Esto refleja tanto la ubicuidad de los productos Microsoft como su posición como objetivo principal de todos los tipos de atacantes.

Apple ocupa un lugar destacado con vulnerabilidades en iOS, macOS, Safari y WebKit. Muchas de las entradas de Apple corresponden a zero-days explotados por proveedores de spyware comercial (NSO Group, Intellexa) y actores estatales.

Google aparece principalmente con vulnerabilidades de Chrome y Android. Los exploits de Chrome son frecuentes porque el navegador es el vector de acceso más directo a endpoints.

Cisco, Fortinet, Palo Alto Networks e Ivanti tienen una presencia significativa con vulnerabilidades en productos de red y seguridad perimetral (routers, firewalls, VPNs). Estas vulnerabilidades son particularmente peligrosas porque los dispositivos afectados son, por definición, accesibles desde Internet y operan con privilegios elevados.

Adobe mantiene presencia con vulnerabilidades en Acrobat Reader, ColdFusion y otros productos. Históricamente, Flash fue un contribuidor masivo, pero su eliminación redujo la superficie de ataque de Adobe significativamente.

Tipos de vulnerabilidad más comunes

Las categorías más frecuentes en el KEV son:

• Ejecución remota de código (RCE): la mayoría de las entradas permite ejecutar código arbitrario de forma remota, el escenario más crítico posible.
• Escalada de privilegios: vulnerabilidades que permiten a un atacante con acceso limitado obtener privilegios de administrador o SYSTEM.
• Bypass de autenticación: vulnerabilidades que permiten acceder a sistemas o funcionalidades sin credenciales válidas.
• Inyección (SQL, comando, LDAP): vectores clásicos que siguen siendo explotados masivamente.

Edad de las vulnerabilidades

El KEV no solo contiene vulnerabilidades recientes. Incluye CVEs que datan de 2002 y anteriores. Esto refleja una realidad incómoda: hay organizaciones ejecutando sistemas con vulnerabilidades de más de 20 años que están siendo explotadas activamente. La persistencia de estos CVEs antiguos en el catálogo indica que los sistemas legacy sin soporte siguen siendo un vector de ataque viable.

Cómo usar el KEV en la práctica

Integración con gestión de vulnerabilidades

El uso más directo del KEV es como filtro de priorización. El flujo recomendado:

1. Escanear los sistemas con un escáner de vulnerabilidades (Tenable, Qualys, Rapid7, OpenVAS).
2. Cruzar los resultados con el catálogo KEV.
3. Priorizar inmediatamente cualquier vulnerabilidad que coincida con una entrada del KEV.
4. Aplicar el parche o la mitigación dentro de los plazos que tu organización defina (siguiendo los plazos de BOD 22-01 como referencia, aunque no seas una agencia federal de EE.UU.).

Automatización con la API

CISA distribuye el catálogo KEV como un archivo JSON estático descargable sin autenticación:

https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

El formato es simple. Cada entrada contiene:

{
  "cveID": "CVE-2024-XXXXX",
  "vendorProject": "Microsoft",
  "product": "Windows",
  "vulnerabilityName": "Microsoft Windows Kernel Privilege Escalation",
  "dateAdded": "2024-11-15",
  "shortDescription": "Microsoft Windows contains a...",
  "requiredAction": "Apply mitigations per vendor instructions...",
  "dueDate": "2024-12-06",
  "knownRansomwareCampaignUse": "Known",
  "notes": ""
}

Un campo particularmente útil es knownRansomwareCampaignUse, que indica si la vulnerabilidad ha sido utilizada en campañas de ransomware. Para organizaciones donde el ransomware es la amenaza principal, este campo permite una priorización adicional.

Monitorización de nuevas adiciones

Configurar alertas para nuevas entradas en el KEV es una práctica fundamental. Las opciones incluyen:

• Polling diario del JSON y comparación con la versión anterior para detectar nuevas entradas.
• Feeds RSS/Atom de CISA que notifican las adiciones.
• Integraciones de terceros en plataformas de SIEM/SOAR que monitorizan el KEV y generan tickets automáticos cuando una nueva entrada afecta a un producto de tu inventario.

La velocidad de respuesta a nuevas adiciones al KEV es un indicador de madurez del programa de gestión de vulnerabilidades.

Métricas de cumplimiento

El KEV proporciona una base excelente para métricas de gestión de vulnerabilidades:

• Porcentaje de CVEs del KEV remediados dentro del plazo. Objetivo: 100% en plazo.
• Tiempo medio de remediación de CVEs del KEV. Cuanto menor, mejor.
• Número de CVEs del KEV activos (sin remediar). Objetivo: cero.
• Tiempo desde la adición al KEV hasta la remediación en tu organización. Mide la velocidad de respuesta.

Estas métricas son concretas, medibles y accionables, a diferencia de métricas basadas en CVSS como "reducir el número de vulnerabilidades críticas", que es vago y difícil de operacionalizar.

KEV y su relación con otros marcos

KEV + CVSS

KEV y CVSS no compiten; se complementan. CVSS describe las características técnicas de la vulnerabilidad. KEV confirma que está siendo explotada. El flujo lógico:

1. Si está en el KEV: prioridad inmediata, independientemente del CVSS.
2. Si no está en el KEV pero tiene CVSS Critical (9.0+): evaluar con EPSS y contexto.
3. Si no está en el KEV y tiene CVSS High (7.0 a 8.9): priorizar según exposición y criticidad del activo.

KEV + EPSS

EPSS predice la probabilidad de explotación futura. KEV confirma la explotación presente. La combinación cubre ambas dimensiones temporales:

• En el KEV: está siendo explotada. Acción inmediata.
• No en el KEV, EPSS alto (>0.5): alta probabilidad de explotación próxima. Priorizar.
• No en el KEV, EPSS bajo (menor a 0.05): baja probabilidad. Parchear en ciclo normal.

KEV + SSVC

SSVC usa el KEV como uno de sus inputs. El eje "Exploitation" de SSVC tiene tres valores: None, PoC, Active. Si una vulnerabilidad está en el KEV, su valor de Exploitation es automáticamente "Active", lo que generalmente conduce a la decisión "Act" (actuar inmediatamente).

Limitaciones del KEV

A pesar de su valor, el KEV tiene limitaciones que los equipos de seguridad deben tener en cuenta.

Conservadurismo

Los criterios de inclusión son estrictos. Hay vulnerabilidades explotadas activamente que no están en el KEV porque no cumplen todos los criterios (falta de CVE ID, falta de remediación disponible, o evidencia insuficiente para los estándares de CISA). El KEV es un subconjunto de las vulnerabilidades explotadas, no el universo completo.

Latencia

Hay un desfase entre el inicio de la explotación y la adición al KEV. Una vulnerabilidad puede estar siendo explotada durante días o semanas antes de que CISA la añada. El KEV no es un sistema de alerta temprana; es un sistema de confirmación.

Sesgo geográfico

El KEV refleja la visibilidad de CISA, que es primariamente estadounidense. Vulnerabilidades explotadas exclusivamente en Asia, África o América Latina pueden tardar más en aparecer en el catálogo si la inteligencia no llega a los canales que CISA monitoriza.

No cubre configuraciones

El KEV solo lista vulnerabilidades de software con CVE ID. No cubre: configuraciones inseguras por defecto, credenciales débiles o por defecto, vulnerabilidades en software sin CVE (muchos productos de nicho, dispositivos IoT), ni problemas de diseño que no se clasifican como CVEs.

Dependencia de vendors

El criterio de "acción de remediación clara" hace que el KEV dependa de que el vendor publique un parche o mitigación. Para software abandonware (sin soporte activo), las vulnerabilidades explotadas activamente pueden no entrar nunca en el KEV aunque representen un riesgo real.

Comparación con otras listas de "must-patch"

CISA KEV vs. Microsoft Security Update Guide

Microsoft clasifica sus vulnerabilidades como "Exploitation Detected", "Exploitation More Likely", "Exploitation Less Likely" o "Exploitation Unlikely". Las vulnerabilidades marcadas como "Exploitation Detected" por Microsoft generalmente aparecen en el KEV poco después. Sin embargo, Microsoft a veces es más rápida en confirmar explotación de sus propios productos, mientras que CISA puede ser más rápida para productos de otros vendors.

CISA KEV vs. Google TAG (Threat Analysis Group)

Google TAG publica análisis detallados de zero-days explotados in the wild, con un foco particular en Chrome, Android y productos de Google. TAG proporciona contexto de atribución (qué actor explotó el zero-day, contra qué tipo de objetivos) que el KEV no incluye. Sin embargo, TAG solo cubre el ecosistema Google.

CISA KEV vs. Mandiant/Google M-Trends

Los reportes anuales de M-Trends de Mandiant documentan las vulnerabilidades más explotadas en los incidentes que investigan. Proporcionan contexto operacional (cómo se explotó, qué actor, qué sector) que el KEV no ofrece, pero se publican anualmente, no en tiempo real.

El KEV como estándar de facto

Aunque BOD 22-01 solo obliga a las agencias federales de EE.UU., el KEV se ha convertido en un estándar de facto para la priorización de vulnerabilidades a nivel global. Las razones de su adopción masiva:

Simplicidad. No hay puntuaciones que interpretar. Si está en la lista, parchea. Si no, evalúa con otros criterios. La claridad binaria es su mayor fortaleza.

Credibilidad. CISA es una agencia gubernamental con acceso a inteligencia de amenazas de múltiples fuentes. Su decisión de incluir un CVE en el KEV tiene peso y credibilidad.

Gratuidad y accesibilidad. El catálogo está disponible como JSON público sin autenticación. Cualquier organización del mundo puede integrarlo en sus herramientas sin coste ni burocracia.

Actualización continua. CISA actualiza el catálogo regularmente, a menudo varias veces por semana. No es un reporte estático publicado una vez al año.

Accionabilidad. Cada entrada incluye la acción de remediación específica y una fecha límite de referencia. No deja dudas sobre qué hacer.

Para las organizaciones que buscan un punto de partida pragmático para la gestión de vulnerabilidades, el KEV es la referencia más accionable disponible. No reemplaza un programa de gestión de vulnerabilidades maduro, pero para organizaciones con recursos limitados, empezar por "remediar todo lo que esté en el KEV" es una estrategia significativamente mejor que "remediar todo lo que tenga CVSS 9.0 o superior".