Listas de materiales de software (SBOM): el inventario de la propia cadena de suministro

Qué es

Una lista de materiales de software (Software Bill of Materials, SBOM) es la lista de piezas de un producto de software: paquetes, versiones, proveedores, licencias, sumas de verificación y las relaciones entre ellos («contiene», «depende de»). Se han impuesto dos formatos. SPDX, de la Linux Foundation, es según la página del proyecto un estándar internacional de libre disponibilidad como ISO/IEC 5962:2021; sus raíces están en la gestión de licencias. CycloneDX es un proyecto de OWASP, estandarizado como ECMA-424 según la página del proyecto, que además de la SBOM describe listas de materiales para servicios, hardware y criptografía, así como el Vulnerability Exploitability eXchange (VEX) —un documento con el que un fabricante comunica si una vulnerabilidad notificada es realmente explotable en su producto. De forma complementaria, el marco SLSA describe niveles para la prueba de procedencia (provenance): una afirmación sobre qué compilación, a partir de qué fuente, generó el artefacto.

Por qué importa

Cuando se conoce una vulnerabilidad en una biblioteca muy extendida, la primera pregunta es: ¿dónde se ejecuta esta versión? Sin lista de materiales, la respuesta es «recompilar y examinar todos los proyectos»; con ella, es una consulta sobre archivos guardados. El mismo inventario responde a cuestiones de licencia (atribución, copyleft) y, según informes generalizados, cada vez se exige más como entregable. Pero una lista de materiales por sí sola no dice si un componente proviene sin alteraciones de la fuente esperada; para eso hace falta la prueba de procedencia.

Cómo aplicarlo

• Generar la lista de materiales durante la ejecución de la versión, y a partir del artefacto compilado (imagen de contenedor, wheel, JAR), no solo del archivo de manifiesto: solo así aparecen la imagen base, los paquetes del sistema y los empaquetados que el manifiesto desconoce.
• Fijar un formato internamente y exportar el otro cuando haga falta; ambos proyectos mantienen listas de herramientas y conversores.
• Guardar el archivo junto al artefacto, con el mismo identificador de versión, y firmarlo cuando los artefactos se firmen.
• Contrastar periódicamente las listas de materiales de todas las versiones entregadas contra las bases de datos de vulnerabilidades; los resultados que, tras revisión, no sean explotables, registrarlos como una afirmación VEX, para que el mismo resultado no se vuelva a evaluar cada semana.
• Formular las reglas de licencia como una comprobación automática sobre la lista de materiales (licencias permitidas, por revisar, prohibidas).
• Mantener los lockfiles y las instalaciones verificadas por hash; la lista de materiales documenta, no impone nada.

Trampas

Una lista de materiales generada a partir del manifiesto fuente difiere del contenido de la imagen. Las listas de materiales envejecen: valen para exactamente una compilación, no para «la aplicación». Las herramientas a menudo no detectan bibliotecas copiadas directamente o renombradas. Un resultado en el contraste es una pregunta, no un diagnóstico —solo la comprobación de si la ruta vulnerable es alcanzable en el propio producto decide la urgencia, y justamente para eso está pensado VEX.