Qué es el riesgo aguas arriba

En una vulnerabilidad corriente, alguien programó mal algo y el error vive en una versión. En un compromiso aguas arriba el problema es distinto: la versión publicada por el proyecto, con su nombre y su firma habituales, lleva algo que no debería llevar. Por eso las preguntas cambian. No basta con mirar una puntuación de gravedad: importa qué versiones exactas salieron, quién las publicó y qué hace falta para volver a un estado confiable.

La confianza que se daba por hecha, «si lo publica el proyecto conocido, es lo que parece», es justo lo que se rompe. La defensa se apoya en conocer qué versiones corren, poder compararlas con lo que el proyecto declara y tener un plan para volver atrás.

Una aplicación casi nunca pide todo lo que lleva. Pide unos pocos componentes (directos) y cada uno arrastra otros (transitivos), que a su vez arrastran otros. Quien lee el archivo de dependencias de una aplicación ve solo el primer nivel; el componente en riesgo puede estar a dos o tres saltos.

Abre dependencias.csv. La columna arrastrado_por dice quién trajo cada fila; sigue la cadena hasta llegar a libcompacta.

El proyecto dice qué versiones están afectadas. El trabajo del analista es comparar cada fila del inventario con ese rango, sin importar si el componente llegó de forma directa o transitiva: una versión afectada lo está igual por el camino que llegue.

Lee comunicado-libcompacta.txt y cuenta en dependencias.csv las aplicaciones que tienen una versión incluida en el rango afectado.

En el archivo caso-real.txt está el resumen de la alerta pública de CISA sobre XZ Utils (29 de marzo de 2024). Observa qué pide la alerta: no pide instalar un parche nuevo, sino volver a una versión anterior no comprometida y buscar actividad maliciosa. Cuando el daño está en lo publicado, lo seguro es retroceder a lo que se sabe limpio.