En los últimos años, la gente se ha vuelto cada vez más consciente de los riesgos inherentes al uso de componentes de código abierto en su software. Teniendo en cuenta que la mayor parte del software es una combinación de código abierto y lógica patentada, saber qué ingredientes se importaron del exterior, directa o transitoriamente, es esencial para una gestión adecuada de los riesgos del producto de software final. Dado que los días en que se rastreaban los ingredientes usando hojas de cálculo complicadas ya quedaron atrás, y además eran lamentablemente ineficientes, la forma principal de lograr dicho seguimiento es utilizando un SBOM, una lista de materiales de software. Al igual que otras listas de materiales, es esencialmente una lista de los ingredientes del software a partir de los cuales se construye el software con la adición de las relaciones entre diferentes ingredientes con un enfoque especial en qué componentes dependen unos de otros.
Actualmente, en el mercado se utilizan dos formatos SBOM principales: SPDX y CycloneDX.
Intercambio de datos de paquetes de software (SPDX) es un proyecto SBOM de código abierto y legible por máquina de la fundación Linux. La última versión del SPDX fue diseñada de acuerdo con el estándar de la NTIA para 'Elementos mínimos para una lista de materiales de software.' Enumera los componentes, derechos de autor, licencias y referencias de seguridad de un software.
CiclónDX (CDX) También es un formato SBOM de código abierto y legible por máquina desarrollado por la comunidad Open Web Application Security Project (OWASP). Como formato BOM, CycloneDX tiene otras aplicaciones más allá de la preparación de listas de materiales de software. También se puede utilizar para compilar componentes, vulnerabilidades y servicios de hardware y sistemas en la nube.
¿Por qué es importante la SBOM?
El SBOM es extremadamente útil para los equipos de desarrollo de software, organizaciones de compras y usuarios finales. Su uso puede ayudar a garantizar que los componentes de código abierto y de terceros estén actualizados y ofrece visibilidad sobre qué dependencias del proyecto tienen vulnerabilidades conocidas que podrían ser explotables en su software. Los compradores de software, por otro lado, pueden utilizar SBOM para analizar el riesgo inherente a un producto mediante evaluaciones de vulnerabilidad.
Sería mejor para las organizaciones colaborar con sus proveedores para garantizar que tengan acceso a información correcta y actualizada sobre los componentes del proyecto que se implementan en los sistemas y/o productos. También deben evaluar sus SBOM periódicamente para ayudar a minimizar los riesgos de utilizar componentes de código abierto y de terceros.
muestras de SBOM
Dependiendo del formato SBOM que utilice, puede haber diferencias en los componentes del SBOM. Dependiendo del tamaño y la complejidad de su proyecto, un archivo SBOM JSON puede llegar fácilmente a miles de líneas o más. Dado que mirar un archivo de mil líneas no es muy informativo, usemos ejemplos existentes más simples para ver qué incluye cada formato SBOM. Analizaremos más de cerca muestras de los dos formatos principales del mercado actual.
SPDX
Puede encontrar el ejemplo SPDX SBOM que seguiremos aquí.
El JSON comienza con información general sobre el archivo en sí: metadatos.
Después de eso, obtenemos los metadatos sobre el software que estamos examinando:
Observe la suma de comprobación y su valor. Cada sección del SBOM incluye el cifrado y el resultado de la parte en cuestión para que las personas que examinan el archivo puedan estar seguras de que el software o componente mencionado es idéntico al que están viendo.
Sin esa garantía, podría encontrar fácilmente varias copias con el mismo nombre de componentes o software y no tendría idea de cuál de estas versiones fue verificada o incluida en el software o en el SBOM que lo describe.
Siguiendo la descripción del software comprobado podemos empezar a ver los componentes:
Puede ver varios campos incluidos para describir la licencia de un componente, su página de inicio, versión, nombre completo, etc.
Otra cosa que puede encontrar en un formato SPDX son las anotaciones: adiciones realizadas posteriormente a una sección e incluyen más información y, a veces, incluso texto libre:
Para obtener más información sobre este formato y sus capacidades, puede visitar el página SPDX de la Fundación Linux.
CiclónDX
El formato CycloneDX SBOM se puede describir en un archivo JSON, un archivo XML o en búferes de protocolo. Para mantener las cosas uniformes y simples, seguiremos un ejemplo simplificado de CycloneDX JSON. El ejemplo descrito se puede encontrar aquí.
El JSON comienza con información general de metadatos sobre el archivo.
Luego se examinaron los metadatos del software:
Después de eso, los componentes del software y sus dependencias:
Tenga en cuenta que este es un ejemplo simplificado y que el formato puede incluir mucha más información. Para obtener una visión más completa de varios casos de uso, puede consultar la página de casos de uso de OWASP CyclonDX. aquí.
Aquí hay un ejemplo de esa página que demuestra la creación de una lista de dependencias:
Y aquí hay una descripción más amplia de los diversos componentes de este formato tomada del OWASP. Capacidades de la lista de materiales página:
Cómo utilizar un SBOM
No se sienta mal si no puede seguir los ejemplos de archivos que se ven aquí. Aunque los archivos JSON son eminentemente legibles por humanos, son mucho más adecuados para ser legibles por máquinas, de modo que el software especializado pueda ingerir la información y generar los resultados que proporciona el análisis.
Puede utilizar una lista de componentes de software para comprobar que no incluye licencias de código abierto no deseadas (línea GPL3.0 o MPL1.1). Puede consultar una lista de dependencias periódicamente para ver si hay actualizaciones disponibles, o comparar los nombres de los paquetes con bases de datos de vulnerabilidades para saber qué dependencias problemáticas incluye su software.
Puede parecer complicado ingerir un SBOM y recuperar toda esa información, pero recuerde que no es necesario que lo haga todo usted mismo. Servicios como la plataforma Scribe Security pueden eliminar muchos de los dolores de cabeza y ofrecer muchos más beneficios. No dude en consultar nuestra plataforma y ver de qué otra manera puede gestionar su riesgo utilizando nuestro sistema de monitoreo continuo durante su ciclo de vida de desarrollo y productos finales.