Lección para el programa, medir el caso y cambiar lo que falló

Los programas de vulnerabilidades se acostumbran a medir lo que es fácil: cuántos avisos llegaron, cuántos hallazgos se cerraron. En un caso como este, la medida que dice algo es otra: cuánto tiempo pasó entre el aviso y saber con exactitud dónde estaba el componente. Todo lo demás, incluso la rapidez del parche, depende de eso.

Esa medida mejora con cosas concretas: listas de componentes al compilar, inventarios de paquetes frecuentes y la lista de proveedores que han entregado la suya.

Abre cronologia-del-caso.csv. El hito del inventario consolidado, el momento en que ya se sabía dónde estaba el componente, se mide desde la publicación del aviso, no desde que la empresa se enteró. Se expresa en minutos para poder comparar casos entre sí sin discutir horas y días.

El otro extremo del caso es el día en que se corrigió la última aplicación afectada. Esa cifra se mide en días calendario y sirve para fijar un objetivo realista la próxima vez: no sirve prometer en el programa lo que el caso demostró imposible.

Mide los días entre el aviso y la última aplicación afectada corregida, según la cronología.

Una revisión posterior sale con acciones. Cada una se convierte en trabajo si tiene un responsable por área y una fecha límite; sin alguno de los dos, es una buena intención. Revisar la lista antes de cerrarla es parte de la revisión.

Mira acciones.csv y comprueba la regla 2 del leeme.txt.

La revisión posterior no busca a quién culpar de que el inventario fuera lento o de que un ticket se cerrara sin evidencia. Busca la condición del sistema que lo permitió: no había lista de componentes, no se reconstruía la imagen base, un ticket podía cerrarse sin adjunto. Una lección que nombra personas hace que la próxima vez se oculten los fallos; una que nombra condiciones permite arreglarlas.