Plan ante un componente comprometido: el lado de gestión

Cuando llega un aviso así, lo primero es acotar: qué aplicaciones usan el componente y en qué versión. El aviso dice qué versiones se ven afectadas; el inventario de componentes (la SBOM de cada aplicación) dice dónde están. Con eso se sabe el alcance real, se priorizan las aplicaciones por su exposición y por los datos que manejan, y se decide quién actúa. Conviene no esperar a que el proveedor aclare todo: el aviso casi nunca explica qué hace la versión alterada, y esa pregunta se contesta mientras ya se acota el alcance.

El aviso afecta a las versiones 5.0.2 y 5.0.3 del componente informes-pdf; las demás no están afectadas. La tabla aplicaciones dice qué versión usa cada aplicación. Una aplicación sin el componente no está afectada, y una con una versión que el aviso no menciona tampoco.

Entre las aplicaciones afectadas no todas tienen la misma prioridad. Dos criterios ordenan la primera mañana: si la aplicación está expuesta a internet (cualquiera puede llegar a ella) y qué datos maneja. La combinación de ambos la sube al primer lugar de la lista del dueño de cada aplicación. Las demás se atienden después, sin esperar a un fin de semana.

En una crisis la decisión se demora si nadie sabe quién la toma. Por eso los planes tienen una matriz que ata cada acción a quien la aprueba. Suspender una aplicación crítica tiene costo para el negocio, y por eso no la decide el analista ni el dueño de una sola aplicación: la decide quien está por encima de los intereses de un área. Leer la matriz y avisar a esa persona es parte del trabajo de gestión.

Un contrato con cláusula de notificación convierte la demora del proveedor en un dato medible: el plazo se cuenta desde que el proveedor detecta el problema hasta que te avisa, no desde que se publicó la versión. La demora no cambia lo que hay que hacer hoy, pero sí lo que se reclama después y lo que se dice al comité.

Las horas se cuentan completas entre los dos momentos de la tabla cronologia, sin cambio de huso.