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

Los equipos de desarrollo de software comenzaron a usar dichas listas hace más de una década para administrar bibliotecas de código abierto y repositorios de terceros. Las preocupaciones respecto de la ciberseguridad pusieron de relieve la importancia de las SBOM después de que ciberataques importantes a la cadena de suministro expusieran debilidades críticas. En la filtración de datos de SolarWinds en 2020 , los  hackers insertaron código malicioso en actualizaciones de software confiables, lo que afectó a 18 000 organizaciones, incluidas varias agencias gubernamentales. Poco después, en 2021, se expuso la vulnerabilidad Log4j, que afectó cientos de millones de dispositivos en todo el mundo  y  reveló aún más cómo los componentes comprometidos podrían amenazar a sistemas enteros.

Estos ataques cibernéticos resaltaron una cruda realidad: las organizaciones, entre ellas, las agencias gubernamentales, no tenían visibilidad de los componentes y dependencias dentro de sus sistemas de software. Esta falta de visibilidad dificulta la evaluación de los riesgos de ciberseguridad y la respuesta eficaz a las amenazas. La urgencia de la amenaza impulsó una acción decisiva por parte de la Casa Blanca. La Orden Ejecutiva 14028 exigió SBOM para todas las adquisiciones federales de software en mayo de 2021.

La Administración Nacional de Telecomunicaciones e Información (NTIA) estableció los requisitos mínimos de las SBOM  que los proveedores de software deben cumplir al vender a entidades de gobierno. En septiembre de 2024, CISA publicó un documento titulado “Framing Software Component Transparency”,  que amplía estos requisitos mínimos y proporciona una orientación más detallada sobre la implementación y gestión de las SBOM en todo el ecosistema de software.

Esta directiva federal ahora sirve como modelo para la transparencia del software en todas las industrias. Por ejemplo, en las industrias de servicios financieros, la Norma de seguridad de datos de tarjetas de pago (PCI DSS) versión 4.0 incluye requisitos para la gestión de inventario de software a fin de proteger los sistemas de pago y abordar las vulnerabilidades. En el sector de la atención médica, la FDA exige SBOM  para  dispositivos médicos, mientras que el Foro Internacional de Reguladores de Dispositivos Médicos (IMDRF) recomienda su uso  para proteger los dispositivos médicos y los sistemas de datos de pacientes.

Estas pautas y recomendaciones de la industria reflejan un cambio más amplio hacia la adopción de SBOM en todo el sector privado. Gartner predice que para 2025, el 60 % de las organizaciones que crean o adquieren software  de infraestructura crítica exigirán SBOM, un aumento frente a menos del 20 % en 2022. Esta adopción está impulsada por la necesidad: un análisis reciente muestra que más del 90 % de las aplicaciones de software modernas contiene dependencias  de código abierto, y el 74 %, dependencias de alto riesgo. Las organizaciones utilizan cada vez más las SBOM para cumplir con los requisitos de conformidad, validar componentes de terceros y abordar vulnerabilidades de seguridad a medida que se descubren.

Al igual que las etiquetas de los alimentos que detallan los ingredientes y sus fuentes, las SBOM proporcionan documentación estructurada de los componentes de software, sus proveedores y las relaciones entre dependencias.

Los requisitos de la SBOM han evolucionado significativamente desde su introducción en la Orden Ejecutiva 14028 (2021). Lo que comenzó como requisitos mínimos de la NTIA se expandió a través de la adopción por parte de las industrias y el ajuste de la normativa. El marco actual, publicado por la CISA en septiembre de 2024, se basa en estos cimientos con una orientación mejorada para facilitar una implementación más amplia.

Las organizaciones enfrentan diferentes requisitos de la SBOM según su sector y sus relaciones con el gobierno federal. Los contratistas del gobierno de EE. UU., los proveedores de infraestructura crítica y las organizaciones en sectores regulados deben cumplir con requisitos específicos de la SBOM. Si bien el gobierno exige que sus proveedores adopten la SBOM, la adopción por parte de organizaciones del sector privado fuera de los contratos gubernamentales es voluntaria, aunque la implementación de prácticas de SBOM se ha vuelto cada vez más importante para reforzar la seguridad de la cadena de suministro y la confianza del cliente.

El marco 2024 de la CISA introduce un modelo de madurez de tres niveles que ayuda a las organizaciones a mejorar progresivamente sus prácticas de SBOM:

• Mínimo previsto: elementos esenciales necesarios para la funcionalidad y la conformidad básicas de la SBOM
  
  
• Práctica recomendada: documentación mejorada que respalde casos de uso de seguridad y conformidad más amplios
  
  
• Objetivo aspiracional: características avanzadas que permitan una visibilidad completa de la cadena de suministro

Los siguientes atributos representan los elementos esenciales necesarios en una SBOM completa:

• Metainformación de la SBOM: datos centrales del propio documento de la SBOM, entre ellos, el autor de los datos de la SBOM, la marca de tiempo de su creación y el componente principal que se está documentando
  
  
• Nombre del proveedor: la entidad que crea, define y fabrica el componente de software
  
  
• Nombre del componente: el nombre designado del componente de software, asignado por el proveedor original
  
  
• Versión del componente: captura los cambios específicos de la versión para dar seguimiento preciso a las actualizaciones y modificaciones.
  
  
• Otros identificadores únicos: incluye tipos de referencia como Common Platform Enumeration (CPE), etiquetas SWID o URL de paquetes (PURL) para lograr un seguimiento preciso de los componentes
  
  
• Hash criptográfico: una huella digital única para cada componente de software que permite la verificación de la integridad y la identificación precisa
  
  
• Relación de dependencia: un mapa estructurado que muestra cómo se interconectan los componentes, cubriendo tanto las dependencias directas como las transitivas
  
  
• Información de licencia: documentación de los términos legales de los componentes de software suministrados
  
  
• Aviso de derechos de autor: entidad que posee los derechos exclusivos y legales de los componentes enumerados

Las dependencias de software crean interconexiones complejas dentro de las aplicaciones modernas. Una SBOM debe capturar estas relaciones claramente, distinguiendo entre dependencias directas (componentes incluidos explícitamente en el software) y dependencias transitivas (componentes incorporados por otras dependencias).

Al documentar las dependencias, las organizaciones deben indicar explícitamente la integridad de su información. El supuesto preestablecido es que la información de dependencia puede estar incompleta a menos que se marque explícitamente lo contrario. Esta transparencia ayuda a los usuarios posteriores a comprender posibles puntos ciegos en su cadena de suministro de software.

Las organizaciones también deben tener en cuenta las dependencias dinámicas cargadas en el tiempo de ejecución y las dependencias remotas llamadas desde servicios externos. Si bien estos pueden no ser parte del desarrollo del software tradicional, comprender estas relaciones es crucial para realizar una evaluación de seguridad exhaustiva.

En las implementaciones reales, no siempre es posible conocer cabalmente todos los componentes del software. Las organizaciones deben manejar estas brechas de manera transparente documentando explícitamente las dependencias desconocidas y la información incompleta. Cuando determinados componentes no pueden documentarse totalmente debido a obligaciones contractuales u otras restricciones, la SBOM debe indicar estas ediciones mientras se preserva la estructura general de dependencias.

En lugar de omitir información incierta, las organizaciones deben marcar explícitamente estas áreas como desconocidas o incompletas. Este enfoque ayuda a los usuarios posteriores a tomar decisiones fundamentadas sobre la gestión de riesgos y las necesidades de investigación más profunda. En el caso de componentes editados, las organizaciones deben mantener tanto SBOM internas completas como versiones editadas adecuadamente para compartirlas externamente.

El proceso de creación y mantenimiento de SBOM involucra a múltiples stakeholders a lo largo del ciclo de vida del desarrollo de software (SDLC). Las organizaciones deben generar SBOM para los componentes de software tanto patentados como de código abierto (OSS). Los proveedores y desarrolladores de software son los principales responsables de generar SBOM iniciales al principio del proceso de desarrollo. Estas SBOM capturan una visión completa de los componentes de todo el código base. Los compradores de software desempeñan un papel clave en la validación y el mantenimiento de estos documentos para las aplicaciones que despliegan.

Los equipos de desarrollo de software integran la generación de SBOM directamente en sus pipelines de integración continua y entrega continua (CI/CD). Durante el proceso de compilación, las herramientas de escaneo automatizadas analizan el código fuente para inventariar todos los componentes, capturando tanto las dependencias directas como las transitivas. Estas herramientas generan archivos de SBOM estandarizados en formatos como SPDX y CycloneDX. (Las etiquetas SWID son una opción menos destacada, pero aún válida). Documentan los metadatos, la información de versión y los detalles de licencia de cada componente.

Los sistemas de control de versiones mantienen registros históricos de los cambios en la SBOM y rastrean cómo evoluciona la composición del software a lo largo del tiempo. Las organizaciones pueden rastrear cambios de versión y parches de seguridad dentro de los componentes de software para cada lanzamiento, lo cual es vital para gestionar vulnerabilidades y manejar incidentes de seguridad.

Los equipos de desarrollo suelen configurar sus pipelines para activar actualizaciones de SBOM en función de eventos específicos: cuando se agregan nuevas dependencias, cuando se actualizan los componentes existentes o cuando se aplican parches de seguridad. Este proceso de actualización continua mantiene la alineación entre la composición real del software y su documentación.

Los puntos de control de calidad a lo largo de todo el proceso de desarrollo validan la integridad y precisión de la SBOM. Estos pasos de validación verifican que cada SBOM cumpla con los estándares requeridos y contenga toda la información necesaria de los componente antes del lanzamiento del software. La validación automatizada reduce las brechas de documentación y mejora la congruencia entre versiones.

El ecosistema de herramientas que respalda la creación de SBOM continúa expandiéndose. Los generadores de SBOM forman la base, escaneando automáticamente el código fuente para identificar los componentes y sus relaciones. Luego, las herramientas de validación cotejan las SBOM generadas con los estándares y especificaciones establecidos, indicando si falta información o si la información es incorrecta. La automatización exitosa de las SBOM se basa en las mejores prácticas establecidas: estandarizar formatos en todos los equipos, implementar convenciones de nomenclatura coherentes, mantener una documentación clara de las reglas de automatización y establecer ciclos de retroalimentación para la mejora continua.

Las plataformas de gestión se basan en estas capacidades, ofreciendo características para el almacenamiento, análisis y distribución de SBOM en todas las organizaciones. Las plataformas avanzadas van más allá al integrar los datos de las SBOM en flujos de trabajo de riesgo y cumplimiento más amplios.

Por ejemplo, las herramientas de automatización pueden mapear las vulnerabilidades de componentes de software específicos, priorizar los esfuerzos de corrección en función de la gravedad y dar seguimiento a los cambios a lo largo del tiempo para identificar riesgos recién introducidos. Al consolidar los datos y proporcionar insights en tiempo real, estas herramientas habilitan a los equipos de desarrollo, seguridad y cumplimiento para colaborar de manera eficaz.

Seleccionar el formato correcto de la lista de materiales de software (SBOM) es crucial para una implementación efectiva. Las SBOM deben admitir la generación automatizada y la legibilidad por máquina a escala en todos los ecosistemas de software. La automatización de los procesos de la SBOM elimina los errores de entradas manuales durante su creación y permite una integración perfecta con herramientas de seguridad y desarrollo.

Existen varios formatos estandarizados que se utilizan para permitir la generación, validación y consumo automatizados de datos de la SBOM, al tiempo que admiten la integración con las herramientas de seguridad y desarrollo actuales. Las organizaciones deben implementar la generación automatizada de SBOM dentro de sus pipelines de CI/CD para asegurarse de que la documentación se mantenga actualizada con los cambios en el software.

La infraestructura actual de la CISA reconoce principalmente dos formatos: SPDX y CycloneDX. Cada uno aborda la documentación de componentes de manera diferente, ofreciendo diferentes niveles de detalle y enfocándose en casos de uso específicos dentro del ciclo de vida del desarrollo de software.

Software Package Data Exchange (SPDX) fue desarrollado por la Fundación Linux, y todo el ecosistema de código abierto y los proveedores de software comercial lo han adoptado de manera generalizada. El formato admite la verificación criptográfica de paquetes y ofrece múltiples opciones de formato legible por máquina, incluidos JSON, RDF, XML y YAML. Su amplia compatibilidad con metadatos permite rastrear de manera detallada la seguridad y la procedencia en toda la cadena de suministro de software.

SPDX destaca en escenarios de cumplimiento de código abierto, proporcionando información detallada sobre licencias y ayudando a las organizaciones a gestionar eficazmente el uso de sus componentes de código abierto. Los principales vendedores de software y proveedores de servicios en la nube adoptaron SPDX por su robusta especificación y el amplio apoyo de su ecosistema.

CyclonedX, desarrollado por la Fundación OWASP, está diseñado específicamente para la seguridad de las aplicaciones y la gestión de riesgos de la cadena de suministro de software. Proporciona características esenciales para la gestión de vulnerabilidades, el seguimiento de componentes y la seguridad de la cadena de suministro, con fuerte énfasis en la integración de VEX (Vulnerability Exploitability Exchange) y el soporte de análisis de contenedores.

Los elementos centrados en la seguridad del formato lo hacen especialmente adecuado para organizaciones que implementan programas integrales de seguridad de la cadena de suministro de software. Su soporte nativo para casos de uso de seguridad ha impulsado la adopción entre los equipos de seguridad y los flujos de trabajo de gestión de vulnerabilidades.

Las etiquetas de identificación de software (SWID) proporcionan un mecanismo estandarizado para la identificación y gestión de software. El formato admite el seguimiento integral de los recursos de software con características para la gestión del ciclo de vida, el seguimiento de parches y el control de inventario en entornos empresariales. En particular, las etiquetas SWID ya no figuran como formato admitido en la guía de 2024 para el mapeo de atributos, pero siguen siendo una opción válida como identificador único dentro de las SBOM.

El análisis de composición de software (SCA) es un proceso activo de ciberseguridad (con herramientas asociadas) que escanea el código en busca de vulnerabilidades, mientras que una lista de materiales de software (SBOM) proporciona un inventario estandarizado de todos los componentes de software en un producto. Aunque ambos ofrecen seguridad de la cadena de suministro de software, sirven para propósitos distintos en los entornos de desarrollo modernos.

Aunque ambas herramientas se centran en los componentes de software, las de SCA escanean y analizan activamente el código durante el desarrollo, centrándose sobre todo en los componentes de código abierto y las dependencias de terceros. Estas herramientas proporcionan insights en tiempo real para la detección de vulnerabilidades, la conformidad de las licencias y la aplicación de políticas de seguridad.

La SBOM funciona como un documento de inventario estandarizado que captura todos los componentes de software, incluido el código patentado. Las SBOM proporcionan transparencia en la composición del software a través de formatos estructurados como SPDX y CycloneDX, pero no incluyen inherentemente capacidades analíticas. Si bien las herramientas de SCA suelen respaldar las prácticas de seguridad internas, las SBOM se establecen cada vez más como obligatorias en virtud de los reglamentos y estándares de la industria.

Las organizaciones generalmente implementan ambas soluciones juntas, empleando herramientas de SCA para monitorear activamente la seguridad durante el desarrollo mientras mantienen las SBOM para cumplir con los requisitos de conformidad y la visibilidad de la cadena de suministro. Las herramientas de SCA a menudo generan y validan SBOM automáticamente, mientras que la documentación de la SBOM ayuda a fundamentar las políticas de escaneo.

La complejidad de las cadenas de suministro de software modernas ha hecho que la adopción de SBOM sea esencial para una gestión de riesgos y una garantía de seguridad cabales. Las organizaciones emplean cada vez más plataformas automatizadas que pueden consolidar los datos de la SBOM con otra información sobre seguridad y conformidad normativa para una toma de decisiones más eficaz.

Los equipos de seguridad integran los datos de las SBOM en sus estrategias más amplias de gestión de gestión de riesgos de aplicaciones a través de plataformas automatizadas que permiten la detección y respuesta a vulnerabilidades en tiempo real. Cuando surgen nuevas vulnerabilidades y exposiciones comunes (CVE), estas plataformas pueden mapearlas instantáneamente a los componentes afectados en toda la cartera de software utilizando inventarios de SBOM. Esto ayuda a las organizaciones a respaldar prácticas de software seguras.

Esta integración permite obtener insights impulsados por IA para la priorización de riesgos, lo que ayuda a los equipos a abordar primero las CVE más críticas. Durante la respuesta a incidentes, los datos detallados de los componentes aportados por las SBOM proporcionan inteligencia crucial sobre los componentes potencialmente comprometidos. Esto permite esfuerzos de corrección específicos y evaluaciones de riesgos más precisas.

Las SBOM desempeñan un papel importante en la gestión de vulnerabilidades al proporcionar un inventario completo de los componentes de software y permitir la identificación rápida de los sistemas afectados cuando se descubren nuevas vulnerabilidades.

Sin embargo, no todas las vulnerabilidades representan el mismo riesgo y determinar la explotabilidad puede ser un desafío. Aquí es donde entra en juego Vulnerability Exploitability Exchange (VEX). VEX es una infraestructura de seguridad que refuerza la utilidad de las SBOM al proporcionar un contexto esencial sobre las vulnerabilidades conocidas. Si bien una SBOM identifica todos los componentes dentro de un producto de software, no indica si las vulnerabilidades descubiertas son explotables. VEX cierra esta brecha al aclarar el impacto real de las vulnerabilidades.

VEX informa a los equipos de respuesta a incidentes de seguridad de productos (PSIRT) y a los equipos de seguridad si hay vulnerabilidades específicas que afectan sus entornos de software. Mediante la infraestructura de Common Security Advisory Framework (CSAF), VEX ofrece actualizaciones de estado legibles por máquina sobre el impacto de las vulnerabilidades. Con esta información, los equipos de seguridad pueden tomar decisiones más rápidas y mejor fundamentadas.

Al integrar los datos de VEX con las SBOM, las organizaciones pueden reducir los falsos positivos, priorizar los riesgos reales y optimizar los flujos de trabajo de gestión de vulnerabilidades. Este enfoque combinado marca un avance significativo en la evaluación de riesgos de seguridad y la corrección específica.

A medida que evolucionan los requerimientos reglamentarios, las organizaciones necesitan capacidades sofisticadas de gestión de cumplimiento normativo que puedan manejar requerimientos complejos de la SBOM. Las SBOM actúan como una forma de confirmación, proporcionando documentación verificable de que los componentes de software se adhieren a estándares como las pautas del Instituto Nacional de Estándares y Tecnologías (NIST) y la Orden Ejecutiva 14028. Al ofrecer registros transparentes de la composición y seguridad del software, las SBOM simplifican las auditorías y demuestran la sintonía normativa en todas las industrias.

Las agencias federales y las industrias reguladas deben demostrar el cumplimiento de diversos marcos, incluidos los lineamientos del NIST y la Orden Ejecutiva 14028. Las plataformas avanzadas de cumplimiento pueden verificar automáticamente que los componentes de software se apeguen a los estándares de seguridad, dar seguimiento al estado de conformidad en múltiples infraestructuras y proporcionar alertas en tiempo real cuando los componentes se desvían de los requisitos. Estas capacidades pueden ayudar a las organizaciones a mantener la conformidad normativa a la vez que reducen la supervisión manual.

Los entornos nativos de la nube y en contenedores plantean desafíos únicos para la gestión de SBOM. La naturaleza dinámica de estos entornos requiere enfoques especializados para manejar arquitecturas complejas de microservicios, imágenes de contenedores que cambian con frecuencia y despliegues que abarcan múltiples proveedores de la nube y plataformas.

Las organizaciones abordan estos desafíos a través de herramientas de SBOM especializadas que se integran directamente con las plataformas de orquestación de contenedores. Estas soluciones permiten la generación de SBOM en tiempo real a medida que se crean y despliegan imágenes de contenedores, al tiempo que proporcionan una visibilidad unificada en los entornos de nube híbrida.

Al automatizar el rastreo de componentes e integrarlos con las herramientas actuales de seguridad en la nube, las organizaciones pueden mantener inventarios precisos de componentes de software y responder rápidamente a las amenazas de seguridad en toda su infraestructura en la nube. Esta capacidad es real tanto si las aplicaciones se ejecutan en contenedores, como funciones sin servidor o en entornos tradicionales.

Las SBOM sirven como base para la gestión de riesgos de la cadena de suministro al permitir una visibilidad completa del software de terceros. Las organizaciones suelen utilizar plataformas impulsadas por IA para analizar los datos de SBOM junto con otras métricas de seguridad, creando una visión holística del estado de sus aplicaciones y su postura de riesgo.

Estas plataformas rastrean las versiones de los componentes, evalúan los riesgos de los proveedores e impulsan la conformidad de las licencias, al tiempo que proporcionan insights aplicables en la práctica para la mitigación de riesgos. La integración de los datos de la SBOM con procesos de gestión de riesgos más amplios permite a las organizaciones tomar decisiones fundamentadas sobre las dependencias de su software y mantener entornos de aplicaciones más seguros y en conformidad.

Las organizaciones pueden enfrentar varios obstáculos importantes al implementar prácticas de SBOM en todo su ecosistema de software. Comprender y abordar estos desafíos es fundamental para que la adopción sea exitosa y para mantener una seguridad de datos eficaz en toda la cadena de suministro.

Los siguientes desafíos suelen surgir cuando las organizaciones implementan prácticas de SBOM:

• Gestionar miles de componentes de software en diversos entornos
  
  
• Integrar datos de SBOM entre diferentes herramientas de desarrollo y plataformas de seguridad
  
  
• Mantener la calidad de los datos, especialmente para software heredado y componentes de terceros
  
  
• Rastrear dependencias en entornos de nube con ciclos de despliegue rápidos
  
  
• Equilibrar las limitaciones de recursos con la necesidad de contar con datos de la SBOM precisos y actualizados
  
  
• Adaptarse a arquitecturas nativas de la nube dinámica donde los componentes cambian con frecuencia

La implementación exitosa de las SBOM requiere un enfoque estratégico en sintonía con los estándares de la industria y las necesidades organizacionales. Entre los elementos clave, podemos mencionar:

• Automatice los procesos a lo largo del ciclo de vida del desarrollo de software
  
  
• Integre perfectamente con los flujos de trabajo y las herramientas de seguridad existentes
  
  
• Utilice una plataforma unificada para la gestión de SBOM

• Implemente elementos esenciales para lograr la funcionalidad y la conformidad básicas de las SBOM
  
  
• Mejore la documentación para casos de uso de seguridad y cumplimiento más amplios
  
  
• Habilite una visibilidad integral de la cadena de suministro a través de características avanzadas

• Genere y actualice SBOM en tiempo real, especialmente en entornos nativos de la nube
  
  
• Documente información desconocida de forma transparente en lugar de omitirla
  
  
• Gestione tanto SBOM internas completas como versiones editadas para compartirlas externamente
  

• Cree políticas claras de gobernanza de las SBOM con auditorías periódicas y validación automatizada
  
  
• Conecte los datos de la SBOM con Vulnerability Exploitability Exchange (VEX) para gestionar mejor las vulnerabilidades

Al seguir estas prácticas, las organizaciones pueden mejorar la visibilidad de la cadena de suministro, reforzar la seguridad y mantener la conformidad mientras abordan los desafíos de la implementación de las SBOM.

El escenario de la seguridad de la cadena de suministro de software continúa evolucionando, impulsando innovaciones en la tecnología y la adopción de las SBOM. A medida que las organizaciones se enfrentan a amenazas cada vez más sofisticadas, la función de las SBOM en la seguridad de los ecosistemas de software se vuelve más crítica.

Varias tendencias clave están dando forma al futuro de la implementación y utilización de las SBOM:

Los avances en materia de inteligencia artificial están transformando el modo en que las organizaciones gestionan y emplean las SBOM. Los sistemas de IA modernos ahora automatizan la generación y el análisis de las SBOM al tiempo que brindan un análisis de riesgos predictivo más preciso y una detección de vulnerabilidades afinada. Esta automatización se extiende a la identificación proactiva de riesgos de seguridad en todas las cadenas de suministro de software.

Un avance significativo es el surgimiento de listas de materiales (BOM) de IA/ML especializadas, que abordan desafíos singulares en el código y los modelos generados por IA. Estas BOM mejoradas documentan las arquitecturas de modelos de IA, los datos de entrenamiento y los métodos de prueba, aportando la transparencia necesaria a los procesos de desarrollo de IA.

El escenario de seguridad para la gestión de SBOM continúa evolucionando. Blockchain y tecnología de contabilidad distribuida ofrecen nuevas soluciones para el almacenamiento y el intercambio seguro de las SBOM, creando pistas de auditoría inmutables que son particularmente valiosas para sistemas de infraestructura críticos. Las organizaciones exigen cada vez más datos de las SBOM aplicables en la práctica que permitan una rápida identificación de los componentes en riesgo y una corrección optimizada.

Blockchain puede mejorar la seguridad de las SBOM al proporcionar almacenamiento a prueba de manipulación, permitir la verificación descentralizada y facilitar el intercambio seguro entre organizaciones con estrictos controles de acceso.

Esta convergencia tecnológica impulsa la adopción de plataformas unificadas que se integran con las prácticas de DevSecOps actuales. Estas soluciones automatizan todo el ciclo de vida de las SBOM, desde la fusión de diferentes fuentes de datos hasta la gestión de aprobaciones en múltiples versiones de software y ramas, a la vez que proporcionan inteligencia para la mitigación de riesgos.