Las primeras 24 horas de una vulnerabilidad en una biblioteca omnipresente

Cuando una vulnerabilidad crítica afecta a un componente que está en muchas aplicaciones, la primera hora no se gasta en parchear. Se gasta en ordenar: quién coordina, por dónde se habla y cuándo se vuelve a informar. Sin eso, cada equipo hace su propia búsqueda, nadie sabe qué ya se miró y los mensajes a la gerencia se contradicen.

Parchear a ciegas el primer día tiene otro problema: todavía no se sabe dónde está el componente ni en qué versión. Actualizar lo que se conoce da la falsa sensación de avance mientras lo que no se conoce sigue abierto.

El reloj de una respuesta no empieza cuando la empresa se entera, empieza cuando el aviso se publica: desde ese momento cualquiera con interés puede leerlo. La diferencia entre la publicación y la primera acción interna es un número que conviene medir, porque es lo que el programa puede mejorar.

Abre linea-de-tiempo.csv y mide los minutos entre la publicación del aviso y el correo interno de TI a los responsables.

La primera lista rápida suele salir de preguntar a los equipos. Tiene un valor y un límite: lo que dice «sí» es útil enseguida, pero lo que no tiene respuesta no es un «no». Un sistema sin respuesta que además está expuesto a internet es lo que más cuidado pide, porque es donde el desconocimiento cuesta más.

Mira lista-rapida.csv: la columna usa_cronista puede traer «si», «no» o «sin dato».

Una lista rápida se resume en dos números: cuántos sistemas tienen el componente y cuántos no se pueden descartar. El segundo es el que importa para decidir el trabajo del día siguiente, porque incluye lo confirmado y lo desconocido. Lo que se descartó con una respuesta con evidencia sale de la cuenta; lo demás, no.

Aplica la regla 2 del leeme.txt: cuenta los sistemas de la lista que no se pueden descartar.

A las seis de la tarde hay que informar a la gerencia con lo que hay: una lista parcial, sin versiones y con varios sistemas sin respuesta. La tentación es esperar a tener el cuadro completo, o llenar los huecos con una frase tranquilizadora.

Un reporte útil describe el estado real, incluidos los vacíos, y compromete una hora para el siguiente. Callar hasta tener todo deja a la gerencia sin información; prometer más de lo que se sabe obliga a corregir después.