SPDX y CycloneDX: cómo elegir un formato de SBOM
Sytance · Actualizado
SPDX y CycloneDX describen tanto los componentes de software como sus relaciones. La elección depende de la información que necesite el destinatario y de las versiones que puedan procesar sus herramientas. Por tanto, acordar un formato también implica acordar la versión, la codificación y los campos obligatorios.
Necesidades de información del destinatario
Un proveedor de firmware que envía una SBOM a un fabricante puede tener requisitos distintos de los de un equipo que la carga en un servicio de gestión de vulnerabilidades. Las versiones y codificaciones compatibles del destinatario determinan qué archivos puede procesar. Un archivo representativo ayuda a confirmar esa compatibilidad.
Documente la información necesaria, incluida la identidad del producto, los identificadores de componentes, las relaciones, las licencias y cualquier dato sobre vulnerabilidades o procedencia. Si el receptor solo admite una parte del formato, determine si los campos omitidos afectan al propósito del intercambio.
Versiones de las especificaciones y compatibilidad de las herramientas
SPDX 2.3 y SPDX 3.0.1 son especificaciones publicadas distintas. SPDX 3.0.1 utiliza un modelo con perfiles, entre ellos una clase SBOM de software. No debe suponerse que un consumidor que acepta JSON de SPDX 2.3 también acepta un documento 3.x.
La descripción general de la especificación CycloneDX enumera la versión 1.7. Su modelo de objetos incluye componentes, servicios, relaciones de dependencia e información sobre vulnerabilidades. Un productor puede admitir una especificación reciente mientras que un importador posterior solo admite una versión anterior.
| Detalle del intercambio | Ejemplo de SPDX | Ejemplo de CycloneDX |
|---|---|---|
| Versión | 2.3 o 3.0.1 | 1.7 |
| Identidad del documento | Modelo de documento específico de la versión | Número de serie y versión de la BOM |
| Dependencias | Relaciones tipificadas | Grafo de dependencias |
| Validación | Reglas para la versión seleccionada | Esquema para la versión seleccionada |
Relaciones y campos de licencia
En SPDX 2.3, CONTAINS describe la inclusión y DEPENDS_ON describe una dependencia. Que un paquete esté contenido en un archivo es distinto de que otro paquete lo necesite para compilarse o ejecutarse. Al importar, conserve el tipo y el sentido de la relación.
SPDX 2.3 también distingue entre una licencia declarada y una licencia concluida. La declaración de un proveedor y la conclusión de un analista no deben convertirse silenciosamente en el mismo campo. La herramienta receptora debe conservar esta distinción si es relevante para la revisión.
En CycloneDX, examine el grafo de dependencias y las referencias a componentes de la versión seleccionada. Tras la conversión, una lista plana de componentes puede seguir siendo legible, pero perder las rutas necesarias para investigar qué productos utilizan un componente.
Comprobación de la información convertida
Un archivo de prueba pequeño puede revelar pérdidas de información durante la conversión. Incluya un producto, una dependencia directa y una indirecta. Dos versiones del mismo componente, una expresión de licencia y un campo marcado explícitamente como desconocido permiten comprobar más que la simple aceptación del archivo.
- Valide el original con respecto a la versión de especificación declarada.
- Impórtelo en la herramienta receptora e inspeccione el producto de destino.
- Compare las identidades de los componentes, las versiones y el sentido de las relaciones.
- Compruebe los campos de licencia y la representación de la información desconocida.
- Si se admite, vuelva a exportarlo y compare el significado, no el formato del archivo.
Elección de formato para la entrega
Si un cliente exige SPDX 2.3, entregue esa versión con los campos acordados y conserve el registro de origen más completo si la conversión elimina otros datos. Si el flujo de recepción ya consume CycloneDX y conserva el grafo necesario, utilice la versión de CycloneDX admitida.
Si los clientes necesitan ambos formatos, mantenga y pruebe las correspondencias entre sus campos. Documente la información que se pierda o pase a extensiones durante la conversión. La conversión debe transformar los datos de acuerdo con la especificación de destino.
Tras la importación, compruebe si el destinatario todavía puede utilizar la información según lo previsto. En el análisis de vulnerabilidades, esto incluye poder partir de un componente y localizar los productos y versiones que lo utilizan.