Vigilar el catalogo KEV de CISA sin tener un servidor encendido

El catalogo KEV (Known Exploited Vulnerabilities) de CISA es de las pocas fuentes que responden a la pregunta que de verdad ordena una cola de parcheo: de todo lo publicado, que se esta explotando ahora mismo. Ya escribi sobre por que cruzarlo con NVD y EPSS cambia por completo el orden de prioridad. Lo que me faltaba era dejar de mirarlo a mano.

El diseno: sin dependencias, sin servidor

kev-digest es un script de Python que usa solo libreria estandar (urllib, json, hashlib, pathlib) y corre cada tres horas en un cron de GitHub Actions. No hay base de datos: el estado completo vive en un archivo seen_cves.json versionado en el propio repositorio. Cada cambio real (entrada nueva, campo modificado, plazo que entra en la ventana de siete dias, o el caso que mas me interesa: una CVE que llevaba meses en el catalogo y de repente pasa a tener uso confirmado en ransomware) se anade al archivo del dia en digest/ y genera un commit. Si no hay novedades, no se escribe nada: con ocho pasadas al dia, escribir siempre llenaria el historial de commits vacios.

El guardian anti-encogimiento

La parte que de verdad me preocupaba no era detectar cambios, era no destruir el historial por un fallo de red. Si el catalogo llega vacio o con un diez por ciento menos de entradas que la ultima vez, el script aborta sin guardar nada. Una descarga a medias marcaria cientos de CVEs como retiradas y grabaria esa foto como buena, borrando la linea base de un plumazo. Cuando el encogimiento es real (CISA si retira entradas de vez en cuando), se lanza a mano con --force. Es la misma logica que aplicaria a cualquier pipeline que escribe estado persistente: mejor no escribir nada que escribir algo corrupto con confianza.

Enriquecimiento sin volverse caro

Que algo este en KEV dice que se explota, no si es un 9.8 o un 5.4. Las entradas nuevas se enriquecen con EPSS (probabilidad de explotacion en 30 dias, consulta en bloque) y NVD (CVSS y severidad, con cache en disco porque tiene rate-limit). Solo las entradas nuevas: pedir el CVSS de las mas de mil seiscientas que ya estan en seguimiento en cada pasada no aportaria nada y agotaria la cuota.

Donde acaba el dato

data/latest.json es la salida publica, con contrato de campos estable porque algo mas lo consume: la seccion KEV Watch de Blue Team Hub descarga ese JSON ya procesado cada tres horas y lo pinta. El calculo del diff vive en un solo sitio a proposito: dos implementaciones del mismo diff en dos lenguajes acabarian discrepando, y esa discrepancia seria dificil de detectar hasta que alguien confiara en el numero equivocado.

Ahora mismo el catalogo tiene mas de 1.694 CVEs en seguimiento, 352 con uso confirmado en campanas de ransomware. Todo eso corre sin que yo tenga que acordarme de mirarlo, y sin un solo servidor que mantener.