El SBOM en SPDX y en CycloneDX

Un SBOM (lista de materiales de software) es un inventario legible por máquinas de los componentes de un software: cuáles son, qué versión, de quién y cómo se relacionan unos con otros. La lista mínima de datos por componente que fijó la guía de la NTIA de EE. UU. en 2021 tiene siete: nombre del proveedor, nombre del componente, versión, otros identificadores únicos, relación de dependencia, autor del SBOM y fecha de generación. Esa guía ha sido ampliada por CISA con una edición de 2026, así que la lista vigente se consulta en la fuente.

Lo que no es: no dice qué componentes tienen fallos ni cuáles te afectan. Es el inventario contra el que se cruzan los avisos; el cruce es otro paso.

Hay dos formatos abiertos de uso general. SPDX nació en el mundo del cumplimiento de licencias, lo mantiene la Linux Foundation y además está publicado como norma ISO/IEC 5962. CycloneDX nació en la seguridad de aplicaciones, dentro de la comunidad de OWASP. Los dos describen componentes, versiones, identificadores y relaciones, y los dos pueden ir en JSON. En SPDX cada paquete tiene un identificador SPDXID que empieza por SPDXRef-; en CycloneDX cada componente tiene un bom-ref. Un identificador de paquete (el purl) puede viajar en ambos y es lo que permite cruzarlos con una base de avisos.

Los dos formatos no compiten en el trabajo: se genera el que pide quien lo recibe.

Un documento SPDX tiene un encabezado (spdxVersion, creationInfo con quién y cuándo lo creó), una lista de packages y una lista de relationships. Cada paquete lleva su SPDXID, su nombre, su versión, su proveedor (supplier), la licencia concluida y, cuando se conoce, de dónde se descargó. El valor NOASSERTION ya lo viste en la sala de licencias: aquí también aparece donde la herramienta no encontró el dato.

Las relaciones apuntan a los componentes por su SPDXID, de modo que el identificador es el hilo que sigue una lectura.

La cadena generó, para la misma imagen, un CycloneDX y un SPDX. Deberían listar los mismos componentes. Una diferencia no es un detalle de formato: significa que un generador falló, o que se alimentó de otra fuente, y el que se entregue a un cliente estaría incompleto. El cotejo se hace por nombre y versión, y se confirma contra el archivo de bloqueo, que es la fuente de verdad de lo que se instaló.

Para cotejar un documento contra otro se leen los dos de arriba abajo, componente por componente.

Al revisar el documento CycloneDX se nota que ningún componente trae el nombre del proveedor, y que en el SPDX el proveedor de uno de ellos dice NOASSERTION. El proveedor es uno de los datos mínimos: sin él, cuando aparece un aviso no se sabe a quién preguntar ni de dónde se obtuvo el componente. Un SBOM sin ese dato sigue siendo útil para cruzar versiones, pero no cumple el mínimo, y quien lo entrega debe saberlo.

Un hueco conocido y comunicado es mejor que un documento que aparenta estar completo.