La lista de materiales de software (SBOM) es una lista de todos los componentes, bibliotecas y otras dependencias utilizadas en una aplicación de software. Los formatos estándar para SBOM incluyen SPDX, CycloneDX y CPE (Common Platform Enumeration). Estos formatos proporcionan una forma estructurada de representar los componentes y dependencias en una aplicación de software, lo que facilita la comprensión y la gestión de los riesgos de seguridad asociados con esos componentes.
En este artículo, explicaremos, en detalle, cuáles son los distintos formatos y estándares de SBOM, qué debe incluir un SBOM y por qué todas las organizaciones deben usarlo.
¿Qué es un estándar SBOM?
La complejidad y la naturaleza dinámica de las cadenas de suministro de los sistemas de software modernos plantean un desafío importante para la transparencia. Esta falta de transparencia contribuye a los riesgos de ciberseguridad y aumenta los costos asociados con el desarrollo, la adquisición y el mantenimiento. Las consecuencias de esto son de gran alcance y afectan no solo a las empresas sino también a cuestiones colectivas como la seguridad pública y la seguridad nacional en nuestro mundo interconectado.
Una mayor transparencia en las cadenas de suministro de software puede conducir a una reducción de los riesgos y costos de ciberseguridad al:
- Mejorar la identificación de sistemas vulnerables e identificar la causa raíz de los incidentes.
- Disminución del trabajo no planificado e improductivo
- Permitir una diferenciación del mercado y una selección de componentes más informadas.
- Estandarizar formatos en múltiples sectores, lo que lleva a una reducción en la duplicación de esfuerzos.
- Detección de componentes de software sospechosos o falsificados
Recopilar y compartir esta información en un formato claro y consistente puede ayudar a reducir costos, mejorar la confiabilidad y aumentar la confianza en nuestra infraestructura digital.
Para ese propósito, el Grupo de Trabajo sobre Estándares y Formatos de Transparencia de Software de la NTIA se estableció en 2018 para evaluar los formatos actuales de las listas de materiales de software e identificar posibles usos futuros. El grupo examinó los estándares e iniciativas existentes relacionados con la identificación de componentes externos y bibliotecas compartidas utilizadas en productos de software y la comunicación de esta información en un formato legible por máquina. El grupo no consideró los formatos propietarios. La encuesta original se publicó a finales de 2019 y se actualizó en 2021, centrándose en resaltar los beneficios del ecosistema de herramientas SBOM y la importancia de la coordinación y armonización en el mundo técnico de SBOM. La conclusión clave es que los datos SBOM se pueden transmitir en varios formatos y el ecosistema debería admitir la interoperabilidad entre ellos.
El grupo de trabajo encontró que comúnmente se usan tres formatos:
- Software Package Data Exchange (SPDX®), un formato de código abierto legible por máquina desarrollado por la Fundación Linux y ahora un estándar ISO/IEC
- CycloneDX (CDX), un formato de código abierto legible por máquina desarrollado por la comunidad OWASP
- Identificación de software (SWID), un estándar industrial ISO/IEC utilizado por varios editores de software comercial
Vale la pena señalar que estos tres formatos comparten información común. Sin embargo, tradicionalmente se han utilizado en diferentes etapas del proceso de desarrollo de software y están destinados a públicos diferentes. Analizaremos cada uno de estos formatos con gran detalle en este artículo.
¿Qué debe incluir una SBOM?
Los componentes mínimos de la NTIA de un SBOM, denominados elementos, constan de tres áreas amplias e interrelacionadas. Estos elementos permiten un enfoque flexible para la transparencia del software, abordando tanto la tecnología como la operación funcional. Es posible que se agreguen más detalles o avances técnicos en el futuro. Como se mencionó anteriormente, estos son los componentes mínimos en la actualidad y las organizaciones pueden requerir más. La capacidad de transparencia en la cadena de suministro de software puede mejorar y evolucionar con el tiempo.
Estas elementos mínimos requeridos para SBOM normalmente se agrupan en tres categorías:
- Campos de información: Un SBOM debe incluir datos importantes sobre los componentes de software, como el nombre del componente, el nombre del proveedor, la versión y los identificadores únicos. También debe incluir información sobre las dependencias entre componentes, lo que permite una identificación y seguimiento precisos de todos los componentes de software a lo largo de la cadena de suministro.
- Prácticas y procesos: La documentación del SBOM también debe describir las prácticas y procedimientos estándar para crear y actualizar el SBOM, distribuirlo y acceder a él, así como para manejar errores.
- Soporte de automatización: La lista de materiales del software debe ser legible por máquina y poder generarse automáticamente para un seguimiento continuo de los datos. Por lo general, se encuentra en formatos estándar como etiquetas SPDX, CycloneDX y SWID, que también los hacen legibles para los humanos.
Formato estándar SPDX SBOM
La especificación SPDX® (Software Package Data Exchange) es un estándar ISO/IEC para compartir información sobre componentes de software, licencias, derechos de autor y detalles de seguridad en múltiples formatos de archivo. Este proyecto ha desarrollado y continúa mejorando un conjunto de estándares de intercambio de datos que permiten a las empresas y organizaciones compartir metadatos de software en un formato que puedan ser entendidos tanto por humanos como por máquinas, simplificando los procesos de la cadena de suministro de software.
La información SPDX se puede vincular a productos de software específicos, componentes o conjuntos de componentes, archivos individuales o incluso pequeños fragmentos de código. El proyecto SPDX se centra en crear y perfeccionar un lenguaje para describir los datos que se pueden intercambiar como parte de un SBOM y la capacidad de presentar estos datos en múltiples formatos de archivo (RDF/XML, XLSX, valor de etiqueta, JSON, YAML). , y XML) para facilitar la recopilación y el intercambio de información sobre paquetes de software y contenido relacionado, lo que resulta en mejoras de tiempo y precisión.
La especificación SPDX describe los campos y secciones necesarios para un documento válido, pero es importante tener en cuenta que no todas las secciones son obligatorias; solo se requiere la sección de información de creación. El creador del documento puede elegir qué secciones y campos desea incluir, que describen el software y la información de metadatos que planean compartir.
SPDX puede capturar eficazmente datos de la lista de materiales del software al representar todos los componentes que se encuentran en el desarrollo y la implementación del software. Se utiliza para documentar imágenes .iso de distribución, contenedores, paquetes de software, archivos binarios, archivos fuente, parches e incluso pequeños fragmentos de código incrustados en otros archivos. SPDX ofrece un conjunto completo de relaciones para conectar elementos de software dentro de documentos y entre documentos SBOM. Un documento SPDX SBOM también puede hacer referencia a fuentes externas, como la base de datos nacional de vulnerabilidades y otros metadatos del sistema de empaquetado.
Hay varios componentes que componen un documento SPDX: información de creación, información de paquete, información de archivo, información de fragmentos, otra información de licencia, relaciones y anotaciones.
Cada documento SPDX se puede representar mediante una implementación completa del modelo de datos y una sintaxis de identificador, lo que permite el intercambio entre diferentes formatos de salida de datos (RDF/XML, valor de etiqueta, XLSX) y la validación formal de la precisión del documento. La versión 2.2 de la especificación SPDX incluye formatos de salida adicionales como JSON, YAML y XML, y también aborda "incógnitas conocidas" como se identifica en el documento SBOM original. Puede encontrar más información sobre el modelo de datos subyacente de SPDX en el Apéndice III de la Especificación SPDX y en el sitio web de SPDX.
Formato estándar CycloneDX SBOM
El proyecto CycloneDX se estableció en 2017 con el objetivo de desarrollar un estándar SBOM totalmente automatizado y centrado en la seguridad. El grupo de trabajo central publica anualmente versiones inmutables y compatibles con versiones anteriores, utilizando un proceso de estándares basado en riesgos. CycloneDX incluye especificaciones existentes, como URL del paquete, CPE, SWID y expresiones e ID de licencia SPDX. Los SBOM se pueden representar en diferentes formatos, incluidos XML, JSON y búferes de protocolo (protobuf).
CycloneDX es una especificación SBOM liviana diseñada para usarse en el análisis de componentes de la cadena de suministro y la seguridad del software. Permite la comunicación del inventario de componentes de software, servicios externos y las relaciones entre ellos. Es un estándar de código abierto desarrollado por OWASP (Open Web Application Security Project).
CycloneDX puede capturar la naturaleza dinámica de los componentes de código abierto cuyo código fuente es accesible, modificable y redistribuible. La especificación puede representar el pedigrí de un componente, incluidos sus antepasados, descendientes y variantes, describiendo el linaje del componente desde cualquier perspectiva, así como las confirmaciones, parches y diferencias que lo hacen único.
El proyecto CycloneDX mantiene una lista de herramientas patentadas y de código abierto conocidas que respaldan o son compatibles con el estándar, que cuenta con el respaldo de la comunidad.
La especificación CycloneDX establece un modelo de objetos detallado que garantiza la coherencia en todas las implementaciones. Se puede validar mediante el esquema XML y el esquema JSON, o mediante la interfaz de línea de comandos CycloneDX. También se proporcionan tipos de medios para XML y JSON para la entrega y el consumo automatizados de formatos compatibles.
Los SBOM de CycloneDX pueden contener la siguiente información: metadatos de BOM, componentes, servicios, dependencias, composiciones y extensiones.
CycloneDX es un estándar SBOM integral que puede caracterizar varios tipos de software, incluidas aplicaciones, componentes, servicios, firmware y dispositivos. Se utiliza ampliamente en todas las industrias para describir paquetes de software, bibliotecas, marcos, aplicaciones e imágenes de contenedores. El proyecto es compatible con los principales ecosistemas de desarrollo y ofrece implementaciones para fábricas de software como acciones de GitHub, lo que permite a las organizaciones automatizar completamente la creación de SBOM.
Etiqueta SWID
Las etiquetas SWID, o etiquetas de identificación de software, se crearon para permitir a las organizaciones rastrear el software instalado en sus dispositivos administrados de manera transparente. El estándar fue establecido por ISO en 2012 y revisado como ISO/IEC 19770-2:2015 en 2015. Estas etiquetas contienen información detallada sobre una versión específica de un producto de software.
El estándar SWID describe un ciclo de vida para el software de seguimiento: se agrega una etiqueta SWID a un punto final durante la instalación de un producto de software y se elimina mediante el proceso de desinstalación del producto. La existencia de una etiqueta SWID específica corresponde directamente a la presencia del software que describe. Múltiples organizaciones de estandarización, como Trusted Computing Group (TCG) y Internet Engineering Task Force (IETF), incorporan etiquetas SWID en sus estándares.
Para realizar un seguimiento del ciclo de vida de un componente de software, la especificación SWID tiene cuatro tipos de etiquetas: primaria, parche, corpus y suplementaria. Las etiquetas de corpus, primarias y de parche tienen propósitos similares en el sentido de que describen la existencia y presencia de diferentes tipos de software, como instaladores de software, instalaciones de software y parches de software, y los posibles estados de los productos de software. Por otro lado, las etiquetas suplementarias proporcionan detalles adicionales que no se encuentran en las etiquetas de corpus, primarias o de parche.
Las etiquetas suplementarias se pueden vincular a cualquier otra etiqueta para proporcionar metadatos adicionales que puedan resultar útiles. Juntas, las etiquetas SWID pueden realizar una variedad de funciones, como descubrimiento de software, gestión de configuración y gestión de vulnerabilidades.
Las etiquetas SWID pueden funcionar como SBOM, ya que proporcionan información de identificación para un componente de software, una lista de archivos y hashes criptográficos para los artefactos del componente e información de procedencia sobre el creador de SBOM (etiqueta) y el creador del componente de software. Las etiquetas también pueden vincularse a otras etiquetas, lo que permite una representación de un árbol de dependencia.
Las etiquetas SWID se pueden generar durante el proceso de construcción y empaquetado, lo que permite la creación automática de un SBOM basado en etiquetas SWID cuando se empaqueta el componente de software correspondiente.
¿Por qué son importantes las listas de materiales de software?
La lista de materiales de software (SBOM) se está volviendo cada vez más importante para las organizaciones, ya que su objetivo es administrar y proteger el software que utilizan. No hay una respuesta corta a la pregunta de ¿Qué es un SBOM?. Los SBOM proporcionan una lista completa de todos los componentes y dependencias que componen un paquete de software, incluida información como números de versión, autores e información de licencia. Esta información es fundamental para la seguridad y el cumplimiento, así como para rastrear la procedencia de los componentes de software.
Muchas organizaciones, incluidas aquellas de industrias reguladas, están utilizando SBOM para garantizar el cumplimiento de regulaciones como el Reglamento General de Protección de Datos (GDPR) y el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). Los SBOM también pueden ayudar a identificar y gestionar vulnerabilidades en el software, así como a rastrear la procedencia de los componentes del software. Además, los SBOM pueden ayudar en la gestión de licencias de software, garantizando que las organizaciones utilicen el software de conformidad con los términos de sus licencias.
Los SBOM también se pueden utilizar para rastrear el uso de software de código abierto, que se está volviendo cada vez más común en el desarrollo de software. Al proporcionar información detallada sobre los componentes de código abierto utilizados en un paquete de software, los SBOM pueden ayudar a las organizaciones a garantizar el cumplimiento de las licencias de código abierto.
Además, los SBOM se pueden utilizar para respaldar el desarrollo y mantenimiento de software. Al proporcionar información detallada sobre los componentes utilizados en un paquete de software, los SBOM pueden ayudar a los desarrolladores a comprender las dependencias de un paquete de software, lo que puede ayudarlos a identificar posibles problemas de compatibilidad y tomar decisiones informadas sobre el uso de nuevos componentes.