SPDX versus CycloneDX

Las listas de materiales de software (Software Bills Of Materials o SBOM) se están convirtiendo en un componente crítico para gestionar vulnerabilidades; sin embargo, muchas organizaciones siguen luchando por entender cuáles los asuntos claves de estas listas y cuáles sus principales diferencias.

¿Qué son los formatos SBOM?

Los formatos SBOM son estándares para definir una estructura unificada para generar listas de materiales de software y compartirlas con los usuarios finales o clientes. Describen la composición del software en un formato común que otras herramientas pueden entender.

Los principales formatos SBOM son Software Package Data Exchange (SPDX), Software Identification (SWID) Tagging y CycloneDX. Solo SPDX y CycloneDX se están adoptando para casos de uso de seguridad. SWID se centra principalmente en la concesión de licencias y, por tanto, queda fuera del ámbito de este debate. Tal y como afirman las principales entidades de ciberseguridad del mundo (como la Agencia de Ciberseguridad y Seguridad de las Infraestructuras o CISA de EE.UU.) existirán múltiples formatos SBOM durante algún tiempo.

SPDX

SPDX es un proyecto de la Fundación Linux que se formó con la intención de crear un formato de intercambio de datos común para la información relacionada con los paquetes de software para compartir y recopilar. Admite la mayor colección de formatos de archivo entre los principales formatos SBOM. Entre ellos se encuentran RDFa, .xlsx, .spdx, .xml, .json y .yaml. También pretende ser una especificación dinámica al poder describir un conjunto de paquetes, archivos o fragmentos de software.

SPDX es el único formato SBOM que ha conseguido la certificación de la Organización Internacional de Normalización (ISO), lo que significa que ha cumplido todos los requisitos de normalización y garantía de calidad definidos por la ISO. Este logro, anunciado en septiembre de 2021, destacó la adopción de SPDX por parte de grandes empresas como Intel, Microsoft, Siemens y Sony, que participan en la comunidad SPDX. 

La especificación SPDX en el momento de escribir este artículo se encuentra en la versión 2.2.2. Para que se considere un documento SPDX válido, deben estar presentes campos y secciones específicas, que se definen en la especificación SPDX. Los documentos SPDX pueden estar compuestos por campos y datos como la información de creación del documento, la información del paquete, la información del archivo, la información del fragmento, la información de la licencia, las relaciones y las anotaciones.

La información de creación del documento se utiliza para la compatibilidad previa y futura cuando se trabaja con herramientas de procesamiento. La información de paquete se utiliza para describir diferentes entidades, como productos, contenedores y componentes, y puede emplearse para agrupar elementos relacionados que comparten contexto. La información de los archivos incluye metadatos de los archivos, como nombres, licencias de suma de comprobación e información de derechos de autor. Los fragmentos son opcionales y se utilizan principalmente cuando los datos se han derivado de una fuente original diferente o están vinculados a otra licencia. SPDX también admite relaciones para documentos, paquetes y archivos. Las anotaciones permiten a un revisor incluir información de sus actividades de revisión en un documento SPDX. 

SPDX también ofrece un perfil SPDX Lite, que es un subconjunto de la especificación SPDX, con el objetivo de alinearse con los flujos de trabajo de industrias específicas, a la vez que se equilibra la adhesión a la norma y especificación general de SPDX. El perfil Lite se centra en los campos de las secciones de creación de documentos e información de paquetes, así como en la información básica que los acompaña. 

CycloneDX

CycloneDX está dirigido por el líder de la comunidad de seguridad Open Web Application Security Project (OWASP) desde hace tiempo. Se trata de un "estándar SBOM ligero autodefinido diseñado para su uso en contextos de seguridad de aplicaciones y análisis de componentes de la cadena de suministro". Su equipo principal está formado por Patrick Dwyer, Jeffry Hesse y el líder de la cadena de suministro de software y creador de Dependency Track, Steve Springett, que preside el grupo. Además de OWASP, entre los partidarios de CycloneDX se encuentran Lockheed Martin, Contrast Security y Sonatype.

Lo que hace que CycloneDX sea único es que fue diseñado desde el principio para ser un formato de lista de materiales y satisfacer una variedad de casos de uso, incluyendo la lista de materiales de software como servicio (SaaSBOM). CycloneDX admite una gran cantidad de casos de uso más allá del software.

Además, admite la referencia a componentes, servicios y vulnerabilidades en otros sistemas y listas de materiales, en un enfoque jerárquico y de distribución que se alinea con la complejidad del ecosistema de software moderno cuando se trata de hardware, nube y SaaS. CycloneDX se refiere a esta capacidad como "BOM-Link". También admite esta capacidad en los formatos JSON y XML. Los usuarios pueden hacer referencia a la URL de la lista de materiales externa o incluso a un URI de BOM-Link que utiliza números de serie y versiones para las listas de materiales externas.

Además de lo anterior, CycloneDX permite realizar un inventario completo y preciso de todos los componentes propios y de terceros para la identificación de riesgos. Lo permite a través de una robusta lista de tipos y clases de componentes, que van más allá del software y las aplicaciones y se adentran en los dispositivos e incluso en los servicios. Permite la identificación de vulnerabilidades a través de tres campos, que son Common Platform Enumeration (CPE), SWID y Package-URL (PURL). La especificación CPE puede utilizarse para vulnerabilidades en sistemas operativos, aplicaciones y dispositivos de hardware. SWID se utiliza para el software instalado y PURL puede utilizarse para los metadatos de los paquetes de software.

CycloneDX ofrece soporte para la verificación de la integridad de los componentes asociados a las listas de materiales que utiliza mediante valores hash y criptografía. La firma de software se está convirtiendo cada vez más en una de las mejores prácticas en el marco de la maduración de la seguridad de la cadena de suministro de software a través de proyectos como Sigstore y su complemento Cosign. CycloneDX también admite la procedencia, que es la capacidad de representar a los autores de los componentes y a los proveedores de los que se obtiene el componente.

Basándose en el concepto de procedencia, CycloneDX puede admitir el origen de los componentes comunicando sus predecedores, descendientes y variantes para describir el historial de un componente. Para los requisitos de la cadena de suministro de software de alta seguridad, la implementación de la procedencia, el origen y las firmas digitales representan capacidades sólidas de la cadena de suministro y son recomendadas por directrices como la gestión de riesgos de la cadena de suministro de ciberseguridad (C-SCRM) del NIST.

También es compatible con el Intercambio de Explotabilidad de Vulnerabilidades (VEX), que proporciona información sobre la posibilidad de explotar las vulnerabilidades conocidas en los productos y componentes de software y puede ser comunicada por los productores de software.

La continuidad de las normas de formato SBOM

Como se desprende de la adopción y el uso por parte de la industria, es probable que estos dos formatos líderes de SBOM permanezcan durante algún tiempo y tanto los productores de software como los consumidores estarían mejor posicionados si pueden soportar ambos formatos. Las principales herramientas de generación de SBOM, como Syft de Anchore, también son compatibles con ambos formatos.

El ecosistema del formato SBOM evolucionará a medida que la adopción y la madurez de estas listas sigan creciendo. Habrá que ver las innovaciones de estos proyectos, así como la entrada de nuevos formatos SBOM potenciales. Aunque hay espacio para el debate sobre qué formato puede ser superior, la necesidad de transparencia y seguridad en la cadena de suministro de software se está convirtiendo en algo innegociable a medida que los actores maliciosos aumentan rápidamente su uso de este vector de ataque.