Cronología de un aviso real y qué se supo cuándo

Una cronología útil separa tres relojes que en la práctica se confunden. El primero es el reloj público: cuándo se publica el identificador, la corrección y la gravedad. El segundo es el reloj de la amenaza: cuándo se sabe que el fallo ya se usa contra sistemas reales; en Estados Unidos lo marca la lista de vulnerabilidades explotadas conocidas de CISA (KEV), que además fija una fecha límite para sus agencias. El tercero es el reloj propio: cuándo se enteró tu equipo, cuándo supo dónde estaba el componente y cuándo actuó.

Medir solo el primero lleva a conclusiones cómodas («el aviso salió el viernes y el lunes ya lo teníamos»). Lo que decide el riesgo es el tiempo entre el segundo y el tercero.

La lista KEV de CISA incluye una vulnerabilidad cuando hay evidencia de explotación activa, y asigna a cada entrada una fecha límite de corrección para las agencias federales. Es una referencia útil para fijar plazos internos, aunque no obligue a una empresa privada.

Abre publico/fuentes-oficiales.txt.

El tiempo hasta el primer inventario es la medida que más pesa en una respuesta: mientras no sepas dónde está el componente, no puedes mitigar ni priorizar. Se cuenta desde la publicación del aviso hasta que existe una primera lista de aplicaciones que lo contienen, aunque sea incompleta.

Cruza la fecha de publicación de las fuentes oficiales con empresa/linea-de-tiempo-retrospectiva.csv.

En los avisos masivos es normal que aparezcan identificadores posteriores: una corrección que no cubre todos los casos, una variante, un fallo vecino. La página de seguridad del proyecto es la fuente que enlaza cada CVE con la versión que lo corrige. Un equipo que cierra el asunto con la primera versión corregida puede quedar expuesto a lo que vino después.

Lee el bloque de la página de seguridad del proyecto.

En la línea de tiempo de Almirez, el equipo actualizó las aplicaciones expuestas y dos días después leyó un aviso posterior. Ese patrón se repite en casi todos los avisos masivos de bibliotecas: la primera respuesta es parcial y hay que dejar el incidente abierto hasta que el flujo de avisos se calme.