Inventario con SBOM, dónde está

Un SBOM (lista de materiales de software) enumera los componentes de una aplicación, con su versión y la relación con ella. La distinción importante en un aviso es entre dependencia directa (la pidió el equipo) y transitiva (la trajo otra biblioteca). Las transitivas son las que nadie recuerda: no aparecen en el archivo que el equipo escribe a mano, y por eso un grep sobre los archivos de dependencias directas deja pasar justo lo que más sorprende.

Un aviso dice qué versiones están afectadas; el inventario dice cuáles tienes. Cruzarlos es una comparación de versiones fila por fila: no vale con que el componente aparezca, hay que mirar si su versión queda por debajo de la corregida. Cuidado con comparar versiones como texto: 4.2.10 es posterior a 4.2.7, aunque «4.2.1» escrito en medio parezca menor.

Abre aviso/aviso-del-fabricante.txt y sbom/componentes.csv.

No todas las aplicaciones afectadas urgen igual. Una expuesta a internet urge más que una interna, y una transitiva es la más fácil de olvidar. El cruce de los dos criterios señala dónde empezar a mitigar y dónde mirar con más cuidado.

Cruza inventario/aplicaciones.csv con sbom/componentes.csv.

Una aplicación sin SBOM no es una aplicación sin la biblioteca: es una aplicación de la que no sabes nada. En un aviso, esas filas ausentes son el riesgo que no puedes medir. Contarlas da el tamaño del punto ciego y la lista de trabajo manual.

Para una aplicación sin SBOM hay dos salidas honestas: obtener la lista de componentes del artefacto que corre en producción (por ejemplo, abriendo el paquete o la imagen desplegada) o preguntar al equipo y dejar la respuesta anotada como no verificada. Lo que no es honesto es contarla como «no afectada» porque nadie la ha encontrado en una búsqueda.