La dependencia que no escribiste

Cuando el servicio de pagos de Cauce declara que usa una librería para procesar tarjetas, se lleva también todo lo que esa librería usa por debajo: sus propias dependencias, y las de esas. La mayor parte del código que acaba en producción entra por ahí. Un fallo conocido en cualquiera de esas piezas es un fallo tuyo en cuanto lo despliegas, aunque no hayas tocado una línea. Por eso la revisión de dependencias no es opcional: es mirar el código que no escribiste pero del que respondes.

Aceptar que respondes por el código heredado es lo que justifica revisarlo con el mismo rigor que el propio.

La revisión de dependencias cruza la lista de librerías del proyecto contra las bases de fallos publicados. Cada coincidencia trae un identificador del fallo, la librería y versión afectadas, una severidad, y —el dato que decide— si existe una versión corregida. En Cauce, Trivy reporta que la librería de procesamiento de pagos, en la versión que usa el proyecto, tiene un fallo de severidad alta con arreglo disponible en una versión posterior. Leer eso es saber qué hay que hacer: fijar la versión corregida en el archivo de dependencias.

Un fallo con arreglo disponible es un fallo con deberes claros: subir a la versión que lo corrige.

La lista de materiales de software es el inventario exacto de cada componente que va dentro de un despliegue: cada librería y su versión, incluidas las heredadas. En Cauce se genera en la cadena y se guarda junto al artefacto de cada versión. Sirve para dos cosas concretas: cuando mañana se publique un fallo nuevo en una librería, se responde en minutos «¿lo llevamos, y en qué versión?» consultando la lista, sin adivinar; y deja por escrito, para una auditoría, qué componía cada versión que se desplegó. Es la memoria de qué desplegaste.

Tener el inventario de cada versión desplegada es lo que convierte «¿nos afecta este fallo nuevo?» en una consulta en vez de una investigación.

La decisión de parar o avisar por una dependencia se sostiene en la evidencia del escaneo, no en el miedo. Un fallo de severidad alta o crítica, explotable en el camino de pagos y con arreglo disponible, se para: hay riesgo real y hay remedio, así que no fusionar hasta subir la versión es lo correcto. Un fallo de severidad baja, o uno en una parte de la librería que el servicio no usa, o sin arreglo todavía, se registra como excepción documentada con su justificación y su fecha de revisión, para no bloquear indefinidamente por algo que no se puede arreglar hoy.

Anclar la parada a severidad, explotabilidad y existencia de arreglo —y documentar la excepción cuando se deja pasar— es lo que hace defendible cada decisión.

Abre el laboratorio de dependencias de Cauce y lee la salida de Trivy. Un fallo es de severidad baja en una parte que el servicio no usa; el otro es el crítico con arreglo en el procesamiento de pagos. Quédate con el crítico.