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

Los equipos de desarrollo de software empezaron a utilizar SBOM hace más de una década para administrar bibliotecas de código abierto y repositorios de terceros. La preocupación por la ciberseguridad situó a los SBOM en el punto de mira después de que importantes ataques a la cadena de suministro sacaran a la luz puntos débiles críticos. En la vulneración de SolarWinds de 2020, los atacantes insertaron código malicioso en actualizaciones de software de confianza, lo que afectó a 18 000 organizaciones, incluidas varias agencias gubernamentales. Poco después, se descubrió la vulnerabilidad Log4j de 2021, que afectó a cientos de millones de dispositivos en todo el mundo  y reveló aún más cómo los componentes comprometidos podían poner en peligro sistemas enteros.

Estos ciberataques pusieron de manifiesto una cruda realidad: las organizaciones, incluidas las agencias gubernamentales federales, carecían de 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ó una SBOM para todas las compras federales de software en mayo de 2021.

La Administración Nacional de Telecomunicaciones e Información (NTIA) estableció los elementos mínimos para las SBOM  que los proveedores de software deben seguir 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 SBOM en todo el ecosistema de software.

Esta directiva federal sirve ahora como modelo para la transparencia del software en todos los sectores. Por ejemplo, en los sectores de servicios financieros, la versión 4.0 del Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (PCI Standard) incluye requisitos de gestión de inventario para proteger los sistemas de pago y dirección de vulnerabilidades. En el sector sanitario, 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 directrices y recomendaciones del sector reflejan un cambio más amplio hacia la adopción de la SBOM en el sector privado. Gartner predice que para 2025, el 60 % de las organizaciones que desarrollen o adquieran software de infraestructura crítica  exigirán SBOM, 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 contienen dependencias de código abierto , y el 74 % contiene dependencias de alto riesgo. Las organizaciones utilizan cada vez más las SBOM para cumplir con los requisitos de cumplimiento, validar los componentes de terceros y dar dirección a las vulnerabilidades de seguridad a medida que se descubren.

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

Los requisitos de 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 ha expandido a través de la adopción de los sectores y el refinamiento regulatorio. El marco actual, publicado por CISA en septiembre de 2024, se basa en estos fundamentos con orientaciones mejoradas para una aplicación más amplia.

Las organizaciones se enfrentan a diferentes requisitos de SBOM en función de su sector y de sus relaciones con el gobierno federal. Los contratistas del gobierno estadounidense, los proveedores de infraestructuras críticas y las organizaciones de sectores regulados deben cumplir requisitos específicos de SBOM. Mientras que el gobierno federal impone la adopción del SBOM a sus proveedores, las organizaciones del sector privado ajenas a los contratos gubernamentales tienen una adopción voluntaria, aunque la aplicación de prácticas SBOM es cada vez más importante para la seguridad de la cadena de suministro y la confianza de los clientes.

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

• Mínimo esperado: elementos esenciales necesarios para la funcionalidad y el cumplimiento básicos de SBOM
  
  
• Práctica recomendada: documentación mejorada que respalde casos de uso de seguridad y cumplimiento más amplios
  
  
• Objetivo ambicioso: características avanzadas que permiten una visibilidad completa de la cadena de suministro

Los siguientes atributos representan los elementos esenciales necesarios en un SBOM completo:

• Metainformación de SBOM: datos básicos del propio documento SBOM, incluido el autor de los datos 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 rastrear con precisión las actualizaciones y modificaciones
  
  
• Otros identificadores únicos: incluye tipos de referencia como Common Platform Enumeration (CPE), etiquetas SWID o URL de paquetes (PURL) para 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 titular de los derechos exclusivos y legales sobre los componentes enumerados

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

Al documentar las dependencias, las organizaciones deben indicar explícitamente la exhaustividad de sus conocimientos. La suposición predeterminada es que la información de dependencia puede estar incompleta a menos que se indique explícitamente lo contrario. Esta transparencia ayuda a los usuarios intermedios a comprender los posibles puntos ciegos en su cadena de suministro de software.

Las organizaciones también deben tener en cuenta las dependencias dinámicas cargadas en tiempo de ejecución y las dependencias remotas llamadas desde servicios externos. Aunque es posible que no formen parte de la compilación tradicional del software, comprender estas relaciones es crucial para una evaluación integral de la seguridad.

En las implementaciones del mundo real, no siempre es posible tener un conocimiento completo de todos los componentes del software. Las organizaciones deben gestionar estas brechas de forma transparente documentando explícitamente las dependencias desconocidas y la información incompleta. Cuando determinados componentes no puedan documentarse en su totalidad debido a obligaciones contractuales u otras limitaciones, la SBOM deberá indicar estas redacciones preservando al mismo tiempo la estructura general de dependencias.

En lugar de omitir información dudosa, las organizaciones deberían marcar explícitamente estas áreas como desconocidas o incompletas. Este enfoque ayuda a los usuarios finales a tomar decisiones informadas sobre la gestión de riesgos y las necesidades de investigación adicional. Para los componentes redactados, las organizaciones deben mantener SBOM internas completas y versiones redactadas adecuadamente para compartir externamente.

El proceso de creación y mantenimiento de SBOM implica a múltiples partes interesadas a lo largo del ciclo de vida del desarrollo de software (SDLC). Las organizaciones deben generar SBOM para los componentes de software propietario y 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 todos los componentes de la base de código. Los compradores de software desempeñan un papel clave en la validación y el mantenimiento de estos documentos para sus aplicaciones implementadas.

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 realizar un inventario de todos los componentes, capturando tanto las dependencias directas como las transitivas. Estas herramientas generan archivos SBOM estandarizados en formatos como SPDX y CycloneDX. (Las etiquetas SWID son una opción menos prominente, 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 de la SBOM, siguiendo la evolución de la composición del software a lo largo del tiempo. Las organizaciones pueden rastrear los cambios de versión y los parches de seguridad dentro de los componentes de software para cada versión, lo que resulta vital para gestionar las vulnerabilidades y gestionar los 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 del pipeline de desarrollo validan la integridad y precisión de SBOM. Estos pasos de validación verifican que cada SBOM cumpla con los estándares requeridos y contiene toda la información necesaria de componente antes del lanzamiento del software. La validación automatizada reduce las lagunas en la documentación y mejora la coherencia entre versiones.

El ecosistema de herramientas que respalda la creación de SBOM sigue expandiéndose. Los generadores SBOM forman la base, escaneando automáticamente el código fuente para identificar los componentes y sus relaciones. A continuación, las herramientas de validación verifican las SBOM generados en función de las normas y especificaciones establecidas, señalando la información que falta o es incorrecta. El éxito de la automatización de la SBOM depende de las buenas prácticas establecidas: estandarizar los formatos entre los equipos, aplicar convenciones de nomenclatura coherentes, mantener una documentación clara de las reglas de automatización y establecer circuitos de feedback para la mejora continua.

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

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

Seleccionar el formato SBOM adecuado es crucial para una aplicación eficaz. Las SBOM deben soportar la generación automatizada y la legibilidad por máquina para escalar a través de los ecosistemas de software. La automatización de los procesos SBOM elimina los errores de entrada manual durante la creación y permite una Integración perfecta con las herramientas de seguridad y desarrollo.

Existen varios formatos estandarizados que se utilizan para permitir la generación, validación y consumo automatizados de datos SBOM, al tiempo que admiten la integración con las herramientas de seguridad y desarrollo existentes. 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 de software.

El marco CISA actual reconoce principalmente dos formatos: SPDX y CycloneDX. Cada uno aborda la documentación de los componentes de forma diferente, ofreciendo diferentes niveles de detalle y centrá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 Linux Foundation y ha obtenido una adopción generalizada en el ecosistema de código abierto y en los proveedores de software comercial. El formato admite la verificación criptográfica de paquetes y ofrece múltiples opciones de formato legible por máquina, como JSON, RDF, XML y YAML. Su rico soporte de metadatos permite un seguimiento detallado de 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 administrar eficazmente el uso de sus componentes de código abierto. Los principales proveedores de software y proveedores de servicio cloud han adoptado SPDX por su sólida especificación y amplio soporte de ecosistema.

CycloneDX, desarrollado por la OWASP Foundation, está diseñado específicamente para la seguridad de las aplicaciones y la gestión de riesgos de la cadena de suministro de software. Ofrece características esenciales para la gestión de vulnerabilidades, el seguimiento de componentes y la seguridad de la cadena de suministro, con especial hincapié en la integración de VEX y el apoyo al 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 del software. El formato admite un seguimiento integral de los activos 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 compatible en la guía de 2024 para la asignación 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 de un producto. Aunque ambos son compatibles con la seguridad de la cadena de suministro de software, sirven para distintos propósitos en los entornos de desarrollo modernos.

Si bien 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 información en tiempo real para la detección de vulnerabilidades, el cumplimiento de licencias y la aplicación de políticas de seguridad.

La SBOM funciona como un documento de inventario estandarizado que captura todos los componentes del software, incluido el código propietario. Las SBOM proporcionan transparencia en la composición del software a través de formatos estructurados como SPDX y CyclonedX, pero no incluyen de forma inherente capacidades. Aunque las herramientas de la SCA suelen respaldar las prácticas de seguridad internas, las SBOM son cada vez más exigidos por los reglamentos y estándares del sector.

Las organizaciones suelen implementar ambas soluciones juntas, utilizando herramientas de SCA para supervisar activamente la seguridad durante el desarrollo y, al mismo tiempo, mantener las SBOM para los requisitos de cumplimiento y la visibilidad de la cadena de suministro. Las herramientas SCA suelen generar y validar SBOM automáticamente, mientras que la documentación de SBOM ayuda a informar 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 la gestión integral de riesgos y la garantía de seguridad. Las organizaciones utilizan cada vez más plataformas automatizadas que pueden consolidar los datos SBOM con otra información de seguridad y cumplimiento para una toma de decisiones más eficaz.

Los equipos de seguridad integran los datos SBOM en sus estrategias más amplias 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 asignarlas instantáneamente a los componentes afectados en toda la portfolio utilizando inventarios SBOM. Esto ayuda a las organizaciones a respaldar prácticas de software seguras.

Esta integración permite obtener conocimiento impulsado por IA para la priorización de riesgos, lo que ayuda a los equipos a dirigir la dirección a las CVE más críticas primero. Durante la respuesta a incidentes, los datos detallados de los componentes de los 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 una rápida identificación de los sistemas afectados cuando se descubren nuevas vulnerabilidades.

Sin embargo, no todas las vulnerabilidades plantean el mismo riesgo y determinar la explotabilidad puede ser difícil. Aquí es donde entra en juego el Vulnerability Exploitability eXchange (VEX). VEX es un marco de seguridad que refuerza los servicios SBOM al proporcionar un contexto esencial sobre las vulnerabilidades conocidas. Aunque una SBOM identifica todos los componentes 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 sobre si determinadas vulnerabilidades afectan a sus entornos de software. Mediante el marco común de asesoramiento de seguridad (CSAF), VEX ofrece actualizaciones de estado legibles por máquina sobre el impacto de la vulnerabilidad. Con esta información, los equipos de seguridad pueden tomar decisiones más rápidas e informadas.

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 automatizada de los riesgos de seguridad y la corrección dirigida.

A medida que evolucionan los requisitos reglamentarios, las organizaciones necesitan capacidades sofisticadas de gestión de cumplimiento que puedan manejar requisitos SBOM complejos. Las SBOM actúan como una forma de certificación y proporcionan documentación verificable de que los componentes de software cumplen con estándares como las pautas del NIST y la Orden Ejecutiva 14028. Al ofrecer un registro transparente de la composición y la seguridad del software, las SBOM simplifican las auditorías y demuestran la alineación normativa en todos los sectores.

Las agencias federales y los sectores regulados deben demostrar que cumplen con varios marcos, incluidas las directrices del NIST y la Orden Ejecutiva 14028. Las plataformas avanzadas de cumplimiento pueden verificar automáticamente que los componentes de software cumplen las normas de seguridad, realizar un seguimiento del estado de cumplimiento de múltiples marcos y proporcionar alertas en tiempo real cuando los componentes se desvían de los requisitos. Estas capacidades pueden ayudar a las organizaciones a mantener un cumplimiento continuo y al mismo tiempo reducir 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 gestionar arquitecturas de microservicio complejas, imágenes de contenedores que cambian con frecuencia e implementaciones que abarcan varios proveedores de servicios en la nube y plataformas.

Las organizaciones abordan estos desafíos a través de herramientas 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 e implementan imágenes de contenedores, al mismo tiempo que proporcionan una visibilidad unificada en todos los entornos de nube híbrida.

Al automatizar el seguimiento de componentes y la integración con las herramientas de seguridad en la nube existentes, 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 se aplica 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 SBOM junto con otras métricas de seguridad, creando una visión holística del estado de sus aplicaciones y la posición de riesgo.

Estas plataformas rastrean las versiones de los componentes, evalúan los riesgos de los proveedores e impulsan el cumplimiento de las licencias, al mismo tiempo que proporcionan conocimientos procesables para la mitigación de riesgos. La integración de los datos SBOM con procesos de gestión de riesgos más amplios permite a las organizaciones tomar decisiones informadas sobre sus dependencias de software y mantener entornos de aplicaciones más seguros y conformes.

Las organizaciones pueden enfrentarse a varios obstáculos importantes a la hora de implementar prácticas de SBOM en todo su ecosistema de software. Comprender y abordar estos desafíos es una parte clave del éxito de la adopción y el mantenimiento de una seguridad de datos eficaz en toda la cadena de suministro.

Los siguientes desafíos surgen a menudo cuando las organizaciones implementan prácticas SBOM:

• Gestión de miles de componentes de software en diversos entornos
  
  
• Integración de datos SBOM entre diferentes herramientas de desarrollo y plataformas de seguridad
  
  
• Mantenimiento de la calidad de los datos, especialmente para el software heredado y los componentes de terceros
  
  
• Seguimiento de dependencias en entornos de nube con ciclos de implementación rápidos
  
  
• Equilibrio de las limitaciones de recursos con la necesidad de datos SBOM precisos y actuales
  
  
• Adaptación a arquitecturas de nube dinámica donde los componentes cambian con frecuencia

La implementación exitosa de SBOM requiere un enfoque estratégico que se alinee con los estándares de los sectores y las necesidades de la organización. Los elementos clave incluyen:

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

• Implementar elementos esenciales para la funcionalidad y el cumplimiento básicos de SBOM
  
  
• Mejore la documentación para casos de uso de seguridad y cumplimiento más amplios
  
  
• Habilite una visibilidad completa 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 la información desconocida de forma transparente en lugar de omitirla
  
  
• Gestione tanto las SBOM internas completas como las versiones redactadas para el uso compartido externo
  

• Cree políticas de gobierno de SBOM claras con auditorías periódicas y validaciones automatizadas
  
  
• Conecte los datos de SBOM con Vulnerability Exploitability eXchange (VEX) para una mejor gestión de las vulnerabilidades.

Al seguir estas prácticas, las organizaciones pueden mejorar la visibilidad de la cadena de suministro, fortalecer la seguridad y mantener el cumplimiento mientras se dirigen a los desafíos de la implementación de SBOM.

El panorama de la seguridad de la cadena de suministro de software sigue evolucionando, impulsando las innovaciones en la tecnología SBOM y su adopción. A medida que las organizaciones se enfrentan a amenazas cada vez más sofisticadas, el papel de los SBOM en la protección de los ecosistemas de software se vuelve más crítico.

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

Los avances en inteligencia artificial están transformando la forma en que las organizaciones gestionan y utilizan las SBOM. Los sistemas de IA modernos ahora automatizan la generación y el análisis de SBOM al mismo tiempo que ofrecen un análisis predictivo de riesgos más preciso y una detección de vulnerabilidades refinada. 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 la aparición de BOM especializadas en IA/ML, que abordan desafíos únicos en código y modelos generados por IA. Estas listas de materiales mejoradas documentan las arquitecturas de los modelos de IA, los datos de entrenamiento y los métodos de prueba, aportando la transparencia necesaria a los procesos de desarrollo de la IA.

El panorama de seguridad para la gestión de SBOM continúa evolucionando. La tecnología blockchain y de contabilidad distribuida ofrece nuevas soluciones para el almacenamiento y el intercambio seguro de SBOM, creando registros de auditoría inmutables que son particularmente valiosos para los sistemas de infraestructuras críticas. Las organizaciones demandan cada vez más datos SBOM que se pueden ejecutar que permiten una identificación rápida de los componentes comprometidos y una corrección racionalizada.

Blockchain puede mejorar la seguridad de SBOM al proporcionar almacenamiento a prueba de manipulaciones, 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 DevSecOps existentes. Estas soluciones automatizan todo el ciclo de vida de SBOM, desde la fusión de diferentes fuentes de datos hasta la gestión de aprobaciones en múltiples versiones de software y sucursales, al tiempo que proporcionan inteligencia para la mitigación de riesgos.