CISA KEV y EPSS: priorizar por evidencia de explotación

Tu escáner devuelve 400 hallazgos y tienes una semana. CVSS puede ordenarlos por gravedad, pero una falla de 9.8 que nadie usa puede esperar, mientras que una de 7.5 que los atacantes ya explotan no debería. Dos fuentes gratuitas te dicen qué fallas se usan en la práctica. El catálogo Known Exploited Vulnerabilities (KEV) de CISA lista fallas con explotación confirmada. El Exploit Prediction Scoring System (EPSS), que mantiene FIRST, estima qué tan probable es que cada falla se explote en los próximos 30 días.

Este artículo explica las dos, muestra cómo encajan junto a CVSS y luego recorre un laboratorio en el que consultas las dos fuentes para los mismos CVE y construyes una tabla de prioridades pequeña. Lo que hay que retener: la gravedad, la evidencia de explotación y tu propia exposición deciden juntas el orden de los parches. Cada una por separado produce un orden equivocado.

Si CVSS te resulta nuevo, lee primero qué es CVSS. Para la diferencia entre vulnerabilidad, amenaza y exploit, consulta qué es una vulnerabilidad.

#Lo que dice CVSS y lo que deja fuera

El Common Vulnerability Scoring System califica una falla según su vector: cómo llega el atacante hasta ella, cuánto esfuerzo requiere, si el atacante necesita privilegios o una acción del usuario, y qué puede dañar la falla. La puntuación base es un número de 0 a 10 construido a partir de esas propiedades.

La puntuación base responde a una pregunta: ¿qué tan grave sería si alguien la usara? No responde si alguien la está usando. CVSS tiene métricas temporales que pueden incluir la madurez del exploit, pero la mayoría de los paneles muestran primero la puntuación base, y ese número no cambia después de publicar el CVE.

Dos CVE del laboratorio de abajo muestran la brecha. CVE-2021-44228 (Log4Shell) tiene una puntuación base de 10.0 en la NVD. CVE-2023-44487 (HTTP/2 Rapid Reset) tiene 7.5. Ordenar solo por puntuación pone Log4Shell primero, y eso es correcto. El problema aparece con un backlog de cuarenta fallas con 9.8 y ninguna señal de que alguna se haya usado. La puntuación te da un punto de partida. No te da un orden.

#CISA KEV: explotación confirmada

El catálogo KEV es la lista de CISA de vulnerabilidades explotadas en la naturaleza. CISA dice que mantiene la fuente autorizada de esa lista y recomienda que las organizaciones la usen como insumo de su marco de priorización. La inclusión depende de evidencia confiable de que la falla se está usando de forma activa. Las entradas llegan a medida que aparece esa evidencia.

El archivo del catálogo que descargué para este artículo (versión 2026.11.06, publicada el 2026-11-06) tiene 1.769 entradas. Cada entrada incluye estos campos:

• cveID, vendorProject, product y vulnerabilityName
• dateAdded, el día en que CISA añadió el CVE
• dueDate, el plazo que fijó CISA
• requiredAction, normalmente una corrección del fabricante o una mitigación
• knownRansomwareCampaignUse, con valor Known o Unknown
• notes y cwes

De las 1.769 entradas, 361 están marcadas como Known para uso en campañas de ransomware. 285 se añadieron en 2026 hasta la fecha de publicación.

Hay dos límites que importan. Primero, el catálogo no está completo. La explotación suele empezar antes de que CISA la confirme, y algunas fallas explotadas nunca reciben una entrada. Un CVE que no aparece en KEV está sin confirmar, lo cual es distinto de estar seguro. Segundo, KEV no dice si tu copia de un producto es vulnerable. Esa respuesta sale de tu inventario.

#De dónde vienen los plazos

La mayoría conoce los plazos de KEV por la BOD 22-01, una directiva operativa vinculante que CISA emitió el 3 de noviembre de 2021. Obligaba a las agencias federales de EE. UU. a remediar las entradas de KEV en seis meses para los CVE con identificador asignado antes de 2021, y en dos semanas para todas las demás vulnerabilidades. El campo dueDate todavía refleja ese modelo en las entradas más antiguas.

La BOD 22-01 ya no es la regla. Su página en cisa.gov indica ahora que fue revocada y reemplazada por la BOD 26-04, que CISA lista con fecha del 10 de junio de 2026. La BOD 26-04 fija plazos de remediación a partir de cuatro factores:

• Estado en KEV: ¿el CVE está en el catálogo?
• Exposición del activo: ¿usuarios no autenticados en redes públicas pueden alcanzar el activo?
• Automatización de la explotación: ¿un adversario puede automatizar cada paso del exploit?
• Impacto técnico: ¿cuánto control da una explotación exitosa?

La Tabla 1 de la BOD 26-04 contiene los plazos. La directiva cuenta días naturales y define las entradas "& forensic triage", que deben remediarse en tres días y luego revisarse en busca de señales de compromiso. Lee la tabla en la página de la directiva para ver los valores exactos. No copies cifras de este artículo ni de publicaciones antiguas.

El propio catálogo muestra las dos épocas. En el archivo que descargué, la diferencia entre dateAdded y dueDate es de 21 días en 1.025 entradas, de 14 días en 286 entradas y de unos seis meses (181 o 182 días) en 249 entradas. Casi todas las entradas de seis meses tienen CVE de 2020 o anteriores, lo que encaja con la regla de la BOD 22-01. Los intervalos de 21 y 14 días son fechas que CISA fijó caso por caso, así que no siguen una regla fija. Hay 152 entradas que mencionan la BOD 26-04 en requiredAction o en notes.

#FIRST EPSS: probabilidad en los próximos 30 días

FIRST, el Foro de Equipos de Respuesta a Incidentes y Seguridad, mantiene EPSS. FIRST lo describe como un modelo de aprendizaje automático que estima la probabilidad de que un CVE publicado se explote en la naturaleza en los próximos 30 días. FIRST publica la puntuación cada día para cada CVE. Los datos son gratuitos y no requieren registro.

Cada CVE recibe dos números:

• La puntuación es una probabilidad entre 0 y 1. Una puntuación de 0,05 significa un 5% de probabilidad de explotación en 30 días. FIRST dice que el modelo está calibrado para que la puntuación coincida con esa tasa.
• El percentil es la posición en el ranking. Un percentil de 0,99 significa que el CVE supera en puntuación al 99% de los CVE puntuados ese día.

La mayoría de las puntuaciones están cerca de cero, porque la mayoría de las vulnerabilidades nunca se explota. Por eso el percentil suele ser más fácil de leer que la puntuación cruda. Una puntuación de 0,909 parece alta por sí sola, y un percentil de 0,998 te indica cómo se compara con el resto de la lista ese día.

FIRST dice que el modelo usa unas 2.850 variables de cinco categorías (código de exploit, comentarios públicos, métricas CVSS, antigüedad y volumen de referencias, entre otras) y que aprende de actividad de explotación observada que aportan socios. Las puntuaciones cambian cuando llegan nuevas señales. La API puede devolver un historial de 30 días para un CVE, lo que ayuda cuando necesitas explicar por qué subió una puntuación.

EPSS tiene un límite claro. Predice actividad de explotación. No dice qué tan grave es una falla y no dice si tus sistemas ejecutan el código afectado. Trata una puntuación alta como un motivo para revisar el activo, y comprueba el activo antes de asumir que está en riesgo.

#Cómo encajan con CVSS

Cada fuente responde a una pregunta distinta:

El orden de los parches sale de combinar las cuatro. Esto es un punto de partida, no una ley. Primero va lo confirmado y alcanzable. Después, lo confirmado pero inalcanzable, y lo no confirmado con EPSS alto y alcanzable. El resto sigue por CVSS y por el valor del activo. La BOD 26-04 combina los mismos tipos de insumos, así que las reglas federales siguen la misma lógica.

#Laboratorio práctico: arma una tabla de prioridades

Necesitas:

• Una shell Bash. La ejecución de referencia usó Git Bash en Windows 11, con curl 8.12.1 y Python 3.12.
• Acceso a internet para www.cisa.gov, api.first.org y services.nvd.nist.gov.
• jq, opcional. jq no estaba instalado en la máquina de referencia, así que cada comando de jq de abajo tiene un equivalente en Python 3.12, y las salidas que se muestran vienen de los comandos de Python.

Estos pasos solo leen catálogos públicos. Ninguno escanea un host. Si después verificas la columna de exposición contra servicios en vivo, hazlo solo en sistemas que sean tuyos o para los que tengas permiso escrito de prueba.

#Paso 1: descarga el catálogo KEV

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
ls -l kev.json

La descarga es silenciosa. En la ejecución de referencia, el archivo pesaba 1.832.349 bytes. Abre el inicio del archivo y revisa catalogVersion y dateReleased antes de confiar en los conteos.

#Paso 2: cuenta las entradas

jq '.vulnerabilities | length' kev.json

En la máquina de referencia, esto devolvió command not found, porque jq no estaba instalado. El equivalente en Python devolvió:

python -c "import json; d=json.load(open('kev.json')); print(len(d['vulnerabilities']))"

1769

El campo count en el nivel superior del archivo debe mostrar el mismo número.

#Paso 3: busca un CVE en KEV

jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | {cveID, dateAdded, dueDate, requiredAction}' kev.json

El equivalente en Python imprimió esto, con requiredAction acortado aquí:

{
  "cveID": "CVE-2021-44228",
  "dateAdded": "2021-12-10",
  "dueDate": "2021-12-24",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. ..."
}

Haz la misma consulta para CVE-2023-4863 y obtendrás dateAdded 2023-09-13 y dueDate 2023-10-04. Las fechas son la razón para guardar el archivo del catálogo: registran cuándo actuó CISA, no solo si actuó.

#Paso 4: pregúntale a EPSS por los mismos CVE

curl -s 'https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2023-4863' | jq '.data'

La respuesta cruda de la ejecución de referencia:

{"status":"OK","status-code":200,"version":"1.0","access":"public","total":2,"offset":0,"limit":100,"data":[{"cve":"CVE-2023-4863","epss":"0.999790000","percentile":"0.999800000","date":"2026-11-07"},{"cve":"CVE-2021-44228","epss":"0.999990000","percentile":"1.000000000","date":"2026-11-07"}]}

Dos detalles importan en el código. Las filas llegan en un orden distinto al de la petición, así que relaciona por cve y nunca por posición. Los valores llegan como texto, así que conviértelos a número antes de ordenar o comparar.

#Paso 5: arma la tabla con un script

Guarda esto como priority.py. Solo necesita la biblioteca estándar de Python.

import json, sys, time, urllib.request

KEV_FILE = sys.argv[1]
CVES = sys.argv[2:]

def get(url):
    with urllib.request.urlopen(url, timeout=60) as r:
        return json.load(r)

kev = {v["cveID"]: v for v in json.load(open(KEV_FILE))["vulnerabilities"]}
epss = {row["cve"]: row for row in get(
    "https://api.first.org/data/v1/epss?cve=" + ",".join(CVES))["data"]}

print("| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |")
print("|---|---|---|---|---|")
for cve in CVES:
    nvd = get(f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve}")
    metrics = nvd["vulnerabilities"][0]["cve"].get("metrics", {})
    cvss = metrics.get("cvssMetricV31", [{}])[0].get("cvssData", {}).get("baseScore", "n/a")
    e = epss.get(cve, {})
    print(f"| {cve} | {cvss} | {'yes' if cve in kev else 'no'} | "
          f"{float(e.get('epss', 0)):.5f} | {float(e.get('percentile', 0)):.5f} |")
    time.sleep(7)  # the NVD API rate-limits requests without a key

Ejecútalo sobre seis CVE: dos de los ejemplos del catálogo y cuatro elegidos para contrastarlos.

python priority.py kev.json CVE-2021-44228 CVE-2023-4863 CVE-2024-3400 CVE-2023-44487 CVE-2023-38545 CVE-2024-3094

Salida de la ejecución de referencia:

| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |
|---|---|---|---|---|
| CVE-2021-44228 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-4863 | 8.8 | yes | 0.99979 | 0.99980 |
| CVE-2024-3400 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-44487 | 7.5 | yes | 0.99999 | 0.99998 |
| CVE-2023-38545 | 9.8 | no | 0.78689 | 0.99591 |
| CVE-2024-3094 | 10.0 | no | 0.90900 | 0.99808 |

El script no rellena la columna de exposición, porque solo tú conoces tu inventario. Así la rellenó la ejecución de referencia y qué cubrió cada comprobación:

• CVE-2021-44228: el find de log4j-core*.jar en el perfil de usuario y en el repositorio no devolvió nada. Resultado: no.
• CVE-2023-4863: una búsqueda de libwebp* en /mingw64, /usr y el perfil de usuario no devolvió nada. Resultado: no.
• CVE-2023-38545: curl --version informa 8.12.1. El rango de la NVD para libcurl afectado va de 7.69.0 hasta, sin incluir, 8.4.0. Resultado: no, para el libcurl upstream. Mira la advertencia de abajo.
• CVE-2024-3094: xz --version informa 5.6.4. La NVD lista 5.6.0 y 5.6.1 como afectadas. Resultado: no.
• CVE-2024-3400 y CVE-2023-44487: no verificados en esta máquina.

La columna de exposición es la que más se equivoca la gente. Las distribuciones Linux y los fabricantes suelen aplicar backports de correcciones, así que el número de versión por sí solo puede engañar. Revisa el aviso del fabricante para tu build antes de marcar una fila como segura.

#Paso 6: lee la tabla

Ordena las filas según la regla de la sección anterior. Si CVE-2021-44228, CVE-2023-4863 o CVE-2024-3400 fueran alcanzables en tu red, serían los primeros parches de la semana, sin importar lo que diga el resto de la lista.

CVE-2023-44487 tiene una puntuación CVSS más baja que CVE-2023-38545, pero está confirmado y su EPSS es 0,99999. En una lista donde ambos son alcanzables, va primero. La falla de 9.8 que CISA no ha confirmado baja de posición.

CVE-2024-3094 es el caso que rompe una regla simple. Los datos de CISA no lo listan, pero su EPSS es 0,909 y su CVSS es 10.0. En esta máquina la versión no es afectada, así que la fila se cierra. En un host con xz 5.6.1, la misma fila pasa al primer lugar, porque la puntuación indica que la actividad de explotación es muy probable y la falla es crítica.

#Errores comunes

• Ordenar solo por CVSS. La puntuación mide impacto, no uso. Pon junto a ella las columnas de KEV y EPSS.
• Tratar KEV como lista completa. Una entrada ausente significa que CISA no ha confirmado la explotación. No significa que la falla sea inofensiva.
• Leer EPSS como impacto o como prueba. EPSS estima actividad de explotación. No te dice que la falla está en tu red.
• Copiar los plazos federales. La BOD 22-01 fue revocada. La BOD 26-04 aplica a las agencias federales. Fuera de ese alcance, sus plazos son un modelo, y tú debes fijar los tuyos según tu riesgo.
• Consultar la API en masa. FIRST diseñó la API de EPSS para consultas puntuales. Para el conjunto completo, descarga el CSV diario.
• Olvidar la fecha. Las puntuaciones de EPSS cambian cada día, y KEV crece cada semana. Escribe la fecha junto a cada tabla.
• Confiar en números de versión sin el aviso del fabricante. Los backports y las opciones de compilación cambian lo que resulta afectado.
• Saltarte la columna de exposición. Una tabla sin datos de activos es una opinión sobre las fallas, no una lista de prioridades para tus sistemas.

#Cómo seguir avanzando

• Lee la página de metodología de EPSS en https://www.first.org/epss/how-it-works, que explica la calibración y los límites.
• Usa el CSV diario de EPSS en https://epss.empiricalsecurity.com/epss_scores-current.csv.gz y cruza ese archivo con el de KEV por cveID. Así revisas cientos de CVE de una sola pasada.
• Lee la BOD 26-04 y su Tabla 1. La directiva menciona el programa Vulnrichment de CISA como fuente del estado en KEV, de la automatización de la explotación y del impacto técnico de los CVE con identificador.
• Añade dos columnas de tus propios registros: si el activo está expuesto a internet y cuánto vale para ti. Esas dos columnas suelen reordenar más la lista que las puntuaciones.

#Fuentes

Los datos de este artículo se leyeron el 2026-11-08 de las fuentes enumeradas en los metadatos del artículo. Los conteos de KEV y las puntuaciones de EPSS cambian con el tiempo, así que revisa la fecha en tu propia ejecución.