¿Qué es una lista de materiales de software (SBOM)?

SBOM en la cadena de suministro de software: lecciones aprendidas de la puerta trasera de XZ Utils

El caso de la puerta trasera de XZ Utils, identificado como CVE-2024-3094, involucró una puerta trasera maliciosa insertada en una utilidad de Linux ampliamente utilizada. Esta vulnerabilidad fue descubierta por Andrés Freund justo antes de su integración en las principales distribuciones de Linux, poniendo en riesgo millones de servidores. El investigador encontró esta vulnerabilidad antes de que entrara en producción, evitando cualquier daño real. Si bien los SBOM no desempeñaron un papel en este caso específico, serían cruciales si la vulnerabilidad se hubiera vuelto salvaje, como se vio con Log4j en 2021. En una vulnerabilidad generalizada como Log4j, las plataformas SBOM podrían ayudar efectivamente a comprender el radio de la explosión. y realizar análisis de impacto. Si se hubiera implementado la vulnerabilidad XZ Utils, herramientas como Scribe Hub podrían haber sido fundamentales para alertar a las empresas, permitiéndoles buscar en su inventario de software, bloquear la implementación de versiones comprometidas y mejorar su postura general de seguridad.

Definición de lista de materiales de software

La lista de materiales de software (SBOM) enumera todos los componentes y dependencias de software involucrados en el desarrollo y entrega de una aplicación. Las SBOM son similares a las listas de materiales (BOM) utilizadas en las cadenas de suministro y la fabricación. No ha habido una característica común para todos los proveedores de la industria de TI para describir con precisión los componentes de código fundamentales sobre los que se construye una aplicación.

El SBOM típico incluiría información de licencia, números de versión, detalles de componentes y proveedores. Una lista formal de todos los hechos reduce los riesgos tanto para el fabricante como para el usuario al permitir que otros comprendan lo que hay en su software y actúen en consecuencia. Los SBOM no son nuevos en la industria del software, pero se están volviendo cada vez más vitales a medida que el desarrollo se vuelve más sofisticado y costoso. Últimamente se han convertido en un requisito básico en numerosas empresas.

Protección de aplicaciones nativas de la nube: el poder de los SBOM mejorados

El auge de las aplicaciones nativas de la nube ha introducido una mayor complejidad a la hora de proteger los entornos de software modernos. Estas aplicaciones, caracterizadas por su naturaleza dinámica y distribuida, estaban compuestas por microservicios interconectados y componentes externos, aumentando la superficie de ataque. Mejorar los SBOM se vuelve fundamental en este contexto, ya que brindan visibilidad detallada de todos los componentes y dependencias dentro de una arquitectura nativa de la nube. Un SBOM eficaz ayuda a identificar vulnerabilidades, garantiza el cumplimiento de los estándares de seguridad y facilita una respuesta rápida a incidentes. Al aprovechar SBOM sólidos, las organizaciones pueden mantener un inventario completo de sus activos de software, realizar un seguimiento de los cambios y detectar posibles riesgos de seguridad de manera temprana. En la era de las aplicaciones nativas de la nube, mejorar las prácticas SBOM es indispensable para reforzar la seguridad y mantener la integridad de ecosistemas de software complejos.

Beneficios del SBOM

Se ocupa de las amenazas a la integridad

Los ataques pueden ocurrir en cualquier punto de una cadena de suministro de software normal, y estos ataques se están volviendo más visibles, disruptivos y costosos en el mundo actual. La integridad se puede mantener utilizando un SBOM verificando que los componentes y archivos que aparecen en él sean los mismos que estaban previstos. Por ejemplo, uno de los componentes del formato CycloneDX es un valor hash que se puede utilizar en la coincidencia exacta de archivos y componentes. Como un SBOM no es un documento estático, debe actualizarse cada vez que haya un cambio en el software descrito o sus componentes.

Permite la visibilidad de los componentes del producto.

Las empresas deben generar confianza en los clientes para generar lealtad y promover la repetición de compras. En lugar de garantías o promesas, los SBOM compartidos brindan una mayor visibilidad de la calidad de las tecnologías que utilizan.

Permite un análisis de vulnerabilidades más sencillo

Las empresas pueden utilizar SBOM para identificar y eliminar vulnerabilidades antes de que lleguen a producción. Las nuevas vulnerabilidades en el software de producción se pueden solucionar rápidamente. Al final, los SBOM ayudan a los ingenieros a descubrir y resolver fallas de seguridad más rápidamente.

Aprovecha la gobernanza de licencias para su producto

La adopción de la lista de materiales de software puede ayudar a mejorar la gobernanza de las licencias de software. Cada pieza de software viene con una licencia que especifica cómo puede usarse y distribuirse legalmente. Los componentes constituyentes de una cadena de suministro que conforman una aplicación completa pueden tener una variedad de licencias diferentes. Cualquier empresa que utilice el programa está legalmente obligada a seguir la licencia. Puede que no haya forma de determinar qué necesitan las licencias o cómo cumplirlas sin una lista de materiales del software.

Principios de una SBOM bien formada

Los componentes mínimos de un SBOM bien formado se dividen en tres categorías:

Campos de información

El propósito de estos campos es proporcionar una identificación adecuada de estos componentes. Esto le permite monitorearlos a lo largo de la cadena de suministro de software y relacionarlos con otras fuentes de datos útiles, como bases de datos de vulnerabilidades o licencias. Algunos ejemplos de campos de datos son el nombre del proveedor, el nombre del componente, la versión del componente, otros identificadores únicos, la relación de dependencia, el autor de los datos SBOM y la marca de tiempo.

Soporte de automatización

Las organizaciones que quieran vigilar de cerca los datos de los componentes de SBOM necesitarán que se proporcionen en un estilo coherente y fácil de entender. Esto se aborda en la sección de requisitos básicos de SBOM en "Soporte de automatización". Al enviar SBOM a través de los límites organizacionales, hay tres estándares para elegir:

1. Intercambio de datos de paquetes de software (SPDX)
2. CiclónDX
3. Etiquetas de identificación de software (SWID)

Estos se analizan con más detalle un poco más adelante en este artículo.

Prácticas y Procesos

Finalmente, la sección "Prácticas y procesos" establece seis estándares sobre cómo y cuándo se deben actualizar y suministrar los SBOM. Son los siguientes:

• Si el componente de software se actualiza con una nueva compilación o versión, se deben producir nuevos SBOM.
• Los autores de SBOM deben incluir componentes de nivel superior, así como sus dependencias transitivas.
• Si el SBOM no ofrece un árbol de dependencias completo, el autor del SBOM debe explicar si esto se debe a que (a) el componente no tiene más dependencias o (b) la existencia de dependencias es desconocida y está incompleta.
• Los SBOM deben distribuirse y entregarse de manera “oportuna”, con “derechos de acceso y funciones adecuados establecidos”.
• Las empresas que quieran mantener en secreto algunos componentes de un SBOM deben especificar parámetros de control de acceso, que contendrían reglas y procedimientos específicos para incorporar información relacionada con SBOM en el manual y las herramientas del usuario. En pocas palabras: si hay algo que debe mantenerse en secreto por el bien de la organización, entonces el proceso para mantenerlo en secreto se define en esta sección. 
• Debido a que los estándares que controlan la generación de SBOM son nuevos, se recomienda a los usuarios de SBOM que perdonen las fallas u omisiones (involuntarias).

Diferentes formatos SBOM

Por supuesto, puede generar manualmente una factura SBOM enumerando los muchos componentes dentro del software que ha producido. Sin embargo, mantener enormes bases de código con docenas o incluso cientos de dependencias y componentes de terceros es una tarea tediosa y que requiere mucho tiempo, especialmente para los desarrolladores que administran grandes bases de código con múltiples componentes y dependencias de terceros. Es posible que algunos desarrolladores hayan incluido componentes de terceros en una aplicación sin documentarlo. Como resultado, es posible que los desarrolladores actuales no estén familiarizados con todo el código base.

Para que la adopción sea una realidad, los SBOM deben cumplir con estándares aceptados por la industria que permitan la interoperabilidad entre diversos sectores y organizaciones. Las organizaciones ya cuentan con la arquitectura para desarrollar, administrar y distribuir datos de componentes de software, gracias a algunos estándares.

SPDX: Intercambio de datos de paquetes de software

El sistema Intercambio de datos de paquetes de software (SPDX) es el principal estándar abierto para formatos de lista de materiales de software desarrollado por la Fundación Linux en 2010. Los componentes de software, los derechos de autor, las licencias y las referencias de seguridad se incluyen en los archivos SPDX. La especificación SPDX es compatible con la propuesta de la NTIA. Estándares mínimos de SBOM y casos de uso. Las organizaciones pueden utilizar SPDX Lite para intercambiar datos, ya que es una versión condensada del estándar SPDX. El SPDX obtuvo un estándar oficial como ISO/IEC 5962 en agosto de 2021.

documento spdx

SWID: etiquetado de identificación de software

El sistema Organización Internacional de Normalización (ISO) comenzó a establecer un estándar para marcar componentes de software con identificaciones legibles por máquina antes del final de la década. Las etiquetas SWID, como se las conoce ahora, son metadatos estructurados integrados en software que transmiten información como el nombre del producto de software, la versión, los desarrolladores, las relaciones y más. Las etiquetas SWID pueden ayudar a automatizar la gestión de parches, la validación de la integridad del software, la detección de vulnerabilidades y a permitir o prohibir instalaciones de software, de forma similar a la gestión de activos de software. En 2012 se confirmó la norma ISO/IEC 19770-2 y se modificó en 2015. Hay cuatro tipos principales de etiquetas SWID que se utilizan en diversas etapas del ciclo de vida del desarrollo de software:

1. Etiquetas del corpus: Se utilizan para identificar y caracterizar componentes de software que no están listos para instalarse. Las etiquetas Corpus están "diseñadas para ser utilizadas como entradas para herramientas y procedimientos de instalación de software", según el Instituto Nacional de Estándares y Tecnología.
2. Etiquetas principales: El propósito principal de una etiqueta es identificar y contextualizar elementos de software una vez que se han instalado.
3. Etiquetas de parche: Las etiquetas de parche identifican y describen el parche (a diferencia del producto principal en sí). Las etiquetas de parche también pueden incorporar, y a menudo lo hacen, información contextual sobre la relación del parche con otros productos o parches.
4. Etiquetas suplementarias: Las etiquetas complementarias permiten a los usuarios de software y a las herramientas de administración de software agregar información útil sobre el contexto de los servicios públicos locales, como claves de licencia e información de contacto de las partes relevantes.

Cuando se trata de determinar qué etiquetas y datos precisos ofrecer con sus productos, las empresas tienen un margen de maniobra considerable. Además de los datos obligatorios, el estándar SWID especifica una serie de componentes y características opcionales. Finalmente, solo se requieren algunas características que caracterizan el producto de software (como el nombre y el ID de etiqueta) y la entidad que lo generó para una etiqueta básica válida y compatible.

CiclónDX

En 2017, la Fundación OWASP lanzó CiclónDX como parte de Dependency-Track, una herramienta de análisis de componentes de software de código abierto. CycloneDX es un estándar liviano para uso en múltiples industrias, con casos de uso como detección de vulnerabilidades, cumplimiento de licencias y evaluación de componentes antiguos. CycloneDX 1.4 se lanzó en enero de 2022. Cyclone DX puede manejar cuatro tipos diferentes de datos:

• Metadatos del diagrama de flujo de materiales: Contiene información sobre la aplicación/producto en sí, como el proveedor, el fabricante y los componentes descritos en el SBOM, así como cualquier herramienta utilizada para crear un SBOM.
• Componentes: Esta es una lista completa de componentes propietarios y de código abierto, junto con información de licencia.
• Servicios: Los URI de punto final, los requisitos de autenticación y los cruces de límites de confianza son ejemplos de API externas que el software puede utilizar.
• Dependencias: incluir conexiones directas e indirectas.

Fuente: CiclónDX

¿Qué aspecto tiene una SBOM?

Para la identificación de riesgos, se requiere un inventario exhaustivo y preciso de todos los componentes propios y de terceros. Todos los componentes directos y transitivos, así como las dependencias entre ellos, deben incluirse en las listas de materiales. Por ejemplo, los siguientes tipos de componentes se pueden describir utilizando CycloneDX:

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "components": [ { " tipo": "biblioteca", "nombre": "nacl-biblioteca", "versión": "1.0.0" } ] }

Formato XML:

 biblioteca-nacl 1.0

¿Por qué firmar su SBOM?

¿Que es una asignatura digital?

A firma digital es exactamente lo que parece: una versión electrónica de la tradicional firma en papel y bolígrafo. Comprueba la validez e integridad de las comunicaciones y documentos digitales utilizando un enfoque matemático sofisticado. Garantiza que el contenido de un mensaje no sea manipulado mientras está en tránsito, lo que nos ayuda a superar el problema de la suplantación y la manipulación en las comunicaciones digitales. La adopción de firmas digitales ha aumentado con el tiempo y son un estándar criptográfico. 

Cómo funcionan las firmas digitales

Las firmas digitales se crean mediante criptografía de clave pública, también conocida como criptografía asimétrica. Un enfoque de clave pública como RSA (Rivest-Shamir-Adleman) Genera dos claves, una privada y otra pública, que conducen a un par de claves relacionadas matemáticamente. Uno de los mecanismos centrales detrás de las firmas digitales es el hash. Transforma eficazmente los datos en una salida de tamaño fijo independientemente del tamaño de la entrada. Esto se hace mediante funciones hash que son básicamente algoritmos, y el resultado que producen se denomina valor hash. Las funciones hash criptográficas generan un valor hash que actúa como una huella digital, haciéndola única para todos. Al igual que la huella digital de cada persona es diferente, diferentes mensajes de entrada generarán diferentes valores hash. Las dos claves criptográficas que se autentican mutuamente de la criptografía de clave pública (PKC) se utilizan principalmente para firmas digitales. El creador de la firma digital utiliza una clave privada para cifrar los datos relacionados con la firma, y ​​esos datos sólo pueden decodificarse utilizando la clave pública del firmante. Así es como un receptor sabe que el remitente no está comprometido y que los datos recibidos son correctos. Actualmente, lidiar con infraestructura de clave pública es costoso y complicado ya que la gente a menudo perder sus claves privadas como si uno perdiera sus llaves físicas. Las autoridades de certificación (CA) actúan como terceros confiables y emiten firmas digitales aceptando, verificando, emitiendo y manteniendo certificados digitales. Las CA ayudan a evitar la creación de certificados digitales falsos. También valida la proveedor de servicios de confianza (TSP). Un TSP es una persona física o jurídica que valida firmas digitales en nombre de una empresa y comunica los resultados de la validación.

Beneficios de un SBOM firmado digitalmente

Un SBOM firmado proporciona una suma de verificación, que es una larga cadena de letras y números que representan la suma de los dígitos precisos de un dato digital y se pueden comparar para encontrar fallas o cambios. Una suma de comprobación es similar a una huella digital. Regularmente comprueba la redundancia (CRC). Los cambios en los datos sin procesar en redes digitales y dispositivos de almacenamiento se detectan mediante un código de detección de errores y una función de verificación. Como una firma digital está destinada a servir como una forma validada y segura de demostrar la autenticidad en las transacciones (es decir, una vez firmada, una persona no puede afirmar lo contrario), incluye a todos los firmantes de los procedimientos y acciones establecidos en el proyecto de ley. 

Problemas con un SBOM sin firmar

Como uno de los propósitos principales de las firmas digitales es la verificación, un SBOM sin firmar no es verificable. Piense en ello como un contrato: si un contrato no ha sido firmado por las partes participantes, no hay una manera real de hacerlo cumplir. De manera similar, un SBOM sin firmar es solo un documento sin firmar: su cliente no puede responsabilizarlo.  Esto también puede generar más problemas en el futuro, ya que un SBOM sin firmar también puede representar riesgos para la seguridad de su organización. Todo lo que de otro modo podría haber estado protegido por un SBOM firmado ahora no está protegido y, por lo tanto, los datos y la información se pueden enviar o replicar en cualquier lugar. Uno de los objetivos principales de los SBOM firmados (la responsabilidad) se pierde cuando un SBOM no está firmado, ya que entonces se pueden realizar cambios sin consecuencias por parte del creador o del cliente. 

Uso de SBOM para mejorar la ciberseguridad

Los SBOM se encuentran entre las mejores formas para que las organizaciones mantengan la seguridad y autenticidad de sus datos y procedimientos. También sentaron un precedente en la industria al aumentar la apertura entre desarrolladores, proveedores de software y clientes. Las organizaciones pueden informar de manera segura a los socios sobre los detalles operativos durante todo el proceso de contratación si existen estándares. Las organizaciones tendrán más éxito en la identificación de fallas, vulnerabilidades y amenazas de día cero a medida que los SBOM se generalicen. La adopción de la lista de materiales de software es una clara ganancia para la seguridad de la cadena de suministro de software en todo el mundo.

Uso de VEX para obtener más usabilidad de su SBOM

Vulnerability Exploitability eXchange (VEX) es un aviso de seguridad destinado a exponer la explotabilidad de las vulnerabilidades en el contexto del producto en el que se encuentran. Al ejecutar un análisis de vulnerabilidades en la mayoría de las aplicaciones modernas, los resultados podrían fácilmente ser cientos o miles de vulnerabilidades. Del número total de vulnerabilidades descubiertas, sólo alrededor del 5% son realmente explotables. También es importante recordar que la explotabilidad casi nunca es una cuestión independiente. La mayoría de las veces es un caso de uso complejo de bibliotecas de código abierto, módulos y el código que los utiliza trabajando juntos lo que convierte una vulnerabilidad en un problema realmente explotable. Hasta que cambie su aplicación y ejecute una nueva SBOM para describirla, el inventario descrito en una BOM generalmente permanecerá estático. La información sobre vulnerabilidades es mucho más dinámica y sujeta a cambios. Tener su información VEX disponible como una lista independiente hace posible actualizar los datos VEX sin tener que generar y administrar listas de materiales adicionales. CISA proporciona una lista de los elementos de datos mínimos recomendados que debería incluirse en un documento o aviso VEX útil. Estos son:

Metadatos VEX: Identificador de formato VEX, Cadena de identificador para el documento VEX, Autor, Función de autor, Marca de tiempo. 

Detalles del producto: Identificador(es) de producto o identificador de familia de producto (p. ej., identificador único o una combinación de nombre del proveedor, nombre del producto y cadena de versión, según lo establecido en la guía SBOM establecida3). 

Detalles de vulnerabilidad: Identificador de la vulnerabilidad (CVE u otros identificadores) y descripción de la vulnerabilidad (por ejemplo, descripción CVE). 

Estado del producto Detalles (es decir, información de estado sobre una vulnerabilidad en ese producto): 

• NO AFECTADO: no se requiere ninguna solución con respecto a esta vulnerabilidad.
• AFECTADO: se recomiendan acciones para remediar o abordar esta vulnerabilidad.
• CORREGIDO: estas versiones del producto contienen una solución para la vulnerabilidad. 
• BAJO INVESTIGACIÓN: aún no se sabe si estas versiones del producto se ven afectadas por la vulnerabilidad. Se proporcionará una actualización en una versión posterior.

Superar los desafíos de la adopción de SBOM

La incorporación de SBOM en el ciclo de vida de desarrollo de software (SDLC) de una organización presenta varios desafíos. En primer lugar, generar y mantener SBOM precisos puede llevar mucho tiempo y ser costoso, y requiere una inversión significativa en herramientas y procesos. Los desafíos de SBOM también incluyen la integración de la gestión de SBOM con los canales de CI/CD existentes, lo que puede implicar la racionalización de la integración de los canales de CI/CD. Además, garantizar la integridad y precisión de los SBOM exige un seguimiento meticuloso de todos los componentes del software, incluidas las dependencias de terceros. Otro obstáculo importante es fomentar una cultura de transparencia y conciencia de seguridad entre los equipos de desarrollo, lo cual es crucial para la adopción exitosa de prácticas SBOM. Superar estos desafíos de SBOM requiere un enfoque estratégico, que combine herramientas sólidas, capacitación efectiva y un fuerte compromiso organizacional para mejorar la seguridad de la cadena de suministro de software.

Resum

En conclusión, si bien los SBOM siguen siendo una idea novedosa para la mayoría de las organizaciones, se espera que la capacidad de producir SBOM sea más significativa en el futuro. Si aún no ha comenzado a incorporar la creación de SBOM en su proceso de entrega de software, este es un gran momento para hacerlo.