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

La SBOM ayuda a mejorar la visibilidad de las cadenas de suministro al enumerar los componentes con los que interactúan estos procesos. Por lo tanto, para elaborar una estrategia de gestión de riesgos de la cadena de suministro de software, debemos comprender la SBOM.

Por estas fechas el año pasado, en 2023, la Comisión de Seguridad e Intercambio emitió un comunicado de prensa sobre una demanda contra una empresa de software con sede en Austin, Texas. La demanda se hacía eco de una preocupación que ha desconcertado a las empresas de software de todo el mundo: la seguridad de la cadena de suministro de software. Los ciberdelincuentes llevan tiempo atacando las cadenas de suministro de software, aprovechando vulnerabilidades como la del marco Log4j para instalar malware.

Esta creciente preocupación por la seguridad de la cadena de suministro es una de las principales razones por las que la lista de materiales de software (SBOM) está encontrando su lugar en las regulaciones administrativas oficiales para la ciberseguridad. Las cadenas de suministro de software suelen ser complicadas, ya que implican múltiples procesos. La SBOM ayuda a mejorar la visibilidad de las cadenas de suministro al enumerar los diferentes componentes y dependencias con los que estos procesos interactúan directamente. Por lo tanto, para elaborar estrategias eficaces de gestión de riesgos de la cadena de suministro de software, debemos comprender la SBOM y su alcance.

Introducción a la SBOM (lista de materiales de software)

Una lista de materiales de software (SBOM) es una lista detallada de las distintas partes del software, incluidos sus componentes de código abierto, bibliotecas y sus relaciones. La idea es proporcionar a las partes interesadas un conocimiento profundo de todo lo que ofrece el software, garantizando así la transparencia en el contexto de la ciberseguridad. Con las transformaciones en las formas de desarrollar y distribuir el software, han surgido complejidades que permiten a los ciberatacantes inventar formas creativas de actuar. Por lo tanto, la SBOM es una red de seguridad esencial que permite tener una visión clara de nuestras aplicaciones.

¿Por qué es esencial la SBOM para la ciberseguridad?

Cuando el presidente Biden hizo hincapié en la SBOM en su orden ejecutiva relativa a la mejora de la ciberseguridad, lo hizo consciente de las vulnerabilidades de la cadena de suministro a las que se dirigen las campañas maliciosas. Una lista anidada como SBOM básicamente desglosa el software en sus componentes y ayuda a identificar estas vulnerabilidades. Aquí hay tres razones por las que SBOM es esencial para la ciberseguridad:

• Transparencia en el software: La SBOM ayuda a las partes interesadas a identificar si hay componentes obsoletos o propensos a riesgos en el software. Si hay, por ejemplo, una biblioteca de cifrado obsoleta o un marco de registro como Log4j, los expertos en seguridad pueden identificar fácilmente el riesgo asociado.
• Seguimiento de componentes de código abierto: Muchas soluciones de software modernas fomentan la integración de componentes y bibliotecas de código abierto. Es posible que no siempre se compruebe su seguridad, por lo que SBOM ayuda a realizar un seguimiento de sus posibles riesgos.
• Evaluación de dependencias: Aunque algunos componentes pueden no suponer una amenaza visible para la ciberseguridad, su dependencia de otros componentes o bibliotecas sí puede suponerla. Por lo tanto, SBOM también ayuda a los expertos en seguridad a examinar estas dependencias e identificar cualquier brecha de seguridad.
• Seguridad de la cadena de suministro: La transparencia dentro de la cadena de suministro en lo que respecta a la postura de seguridad de los distintos componentes de software ayuda a garantizar estrategias de seguridad proactivas contra posibles explotaciones. SBOM ofrece a los compradores toda la información necesaria que puede habilitar estas estrategias para la seguridad de la cadena de suministro.
• Gestión del cumplimiento normativo: SBOM también ayuda a las partes interesadas a evaluar las soluciones de software y sus componentes para el cumplimiento normativo. Con regulaciones estrictas en todos los sectores, incluidos el sanitario, el financiero, el de defensa y otros, el incumplimiento normativo por parte de cualquier componente de software puede detectarse fácilmente.

Componentes clave de una SBOM (lista de materiales de software)

El informe de la NTIA’s, de conformidad con la orden ejecutiva del presidente, sugirió tres componentes interrelacionados en una SBOM que se consideran necesarios para ofrecer la transparencia requerida en el software. Estos "elementos mínimos" pueden proporcionar una visión detallada de la tecnología y el diseño funcional del software, haciéndolo visible para una evaluación de seguridad exhaustiva.

• Campos de datos: Este elemento determina los detalles sobre los componentes del software en una estructura SBOM formal. Los campos de datos incluyen el nombre del proveedor, la versión del componente y la relación de dependencia, entre otros, para ayudar a rastrear posibles vulnerabilidades de seguridad.

• Compatibilidad con la automatización: La compatibilidad con la automatización ofrece los formatos de datos necesarios que permiten una fácil navegación por los datos SBOM y la legibilidad por máquina de los componentes de software. Se trata de un elemento esencial para garantizar una auditoría más rápida y autónoma del software. Las etiquetas CycloneDX, SPDX y SWID son los tres formatos aceptables según el informe.

• Procesos: Se trata de las prácticas necesarias que ayudarían a incorporar la generación y gestión de SBOM en el ciclo de vida de desarrollo seguro del software. Estas prácticas dictan diversos aspectos de SBOM, incluyendo su frecuencia de generación, la profundidad de los componentes y las dependencias incluidas, y las dependencias conocidas/desconocidas, entre otros.

Ventajas de implementar SBOM (lista de materiales de software)

A survey in 2022 sugiere que el 53 % de las empresas de todos los sectores consideran que las SBOM son una herramienta positiva para la presentación de informes y el cumplimiento normativo. Esta acogida tan positiva de las SBOM solo puede atribuirse a la atención al detalle inherente que ofrecen estas listas. Es precisamente esta atención al detalle la que, a su vez, aporta numerosas ventajas a las SBOM:

• Transparencia en toda la cadena de suministro: Los campos de datos y las relaciones que indican las SBOM ayudan a obtener una visión general detallada de toda la cadena de suministro de software. Las diferentes versiones de los componentes de software, sus dependencias y compatibilidades en todo el software, y sus riesgos de seguridad pueden identificarse y analizarse fácilmente.
• Postura de seguridad coherente: Incluso en el caso del software que se adquiere a pesar de los riesgos potenciales sugeridos por su SBOM, los administradores de seguridad pueden estar mejor preparados para cualquier vulnerabilidad. Se pueden tomar medidas proactivas basadas en la SBOM para mitigar cualquier riesgo de seguridad.
• Gestión del cumplimiento: Si bien la SBOM en sí misma es una obligación normativa, también ayuda a las partes interesadas a cumplir estrictamente las normativas destinadas a determinados componentes del software. Además, con auditorías periódicas, la SBOM también puede ayudar a identificar cualquier desviación en el cumplimiento.
• Amenazas de terceros: Cualquier riesgo de seguridad que planteen los componentes de terceros de código abierto en el software puede rastrearse fácilmente con la ayuda de SBOM. Incluso si el proveedor, de forma consciente o inconsciente, pasa por alto una vulnerabilidad de seguridad, SBOM puede ayudar a rastrearla hasta el componente de terceros responsable.

¿Cómo crear y gestionar un SBOM?

Existen herramientas disponibles para crear un SBOM con todos los elementos necesarios. Estas herramientas tienen la función esencial de traducir su análisis de los componentes de software a cualquiera de los estándares SBOM deseados, como SPDX, CycloneDX y otros. Estas herramientas de generación de SBOM también pueden ayudar a las partes interesadas a rastrear cualquier dependencia obsoleta, licencia y otros aspectos similares que puedan dar lugar a vulnerabilidades de seguridad. Así es como funcionan estas herramientas:

• Paso 1 – Integración de la herramienta SBOM en el proceso de CI/CD: Para registrar los distintos componentes del código del software, las herramientas SBOM deben integrarse en el proceso de CI/CD. Estas herramientas pueden instalarse en las instalaciones o en un entorno en la nube, según convenga.
• Paso 2: escanear el repositorio de código: A continuación, la herramienta escanea el código para identificar los diferentes componentes, bibliotecas, marcos de código abierto y otros elementos del software.
• Paso 3: traducción del análisis del código: Una vez escaneada la base de código en busca de todos los componentes y dependencias, los datos se traducen a uno de los formatos SBOM estándar, según se desee.
• Paso 4: generación de SBOM: Los datos SBOM traducidos pueden exportarse finalmente en formato XML o JSON para su posterior revisión. La NTIA informa de que es obligatorio generar un nuevo SBOM cada vez que se actualiza un componente del software.

Normas y directrices SBOM

Las normas y directrices para la generación de SBOM ayudan a mantener la uniformidad en la estructura de la SBOM, al tiempo que cubren todas las bases de la lista anidada de componentes de software, bibliotecas y mucho más. Estas directrices también son necesarias para fomentar la generación y el procesamiento automatizados de la SBOM.

• Intercambio de datos de paquetes del sistema (SPDX): Este estándar abierto puede ayudar a crear un lenguaje legible que se pueda traducir a formatos de archivo como XML, JSON, YAML y otros. El estándar puede describir de manera eficiente los diferentes componentes de software durante el desarrollo y la implementación mediante la recopilación de datos en forma de información de creación, información de archivos, información de paquetes y más.
• CycloneDX: Este formato se lanzó con un enfoque específico en la seguridad y la generación automatizada de SBOM. La especificación ligera puede garantizar un análisis exhaustivo de los componentes de software, su interacción con servicios externos y las relaciones entre ellos. El estándar de código abierto también se adapta bien a los componentes dinámicos de código abierto que se modifican y redistribuyen de forma regular.
• Etiquetas de identificación de software (etiquetas SWID): Establecidas por la ISO en 2012, las etiquetas SWID tienen por objeto realizar un seguimiento del componente de software a lo largo de su ciclo de vida. Estas etiquetas, a saber, primaria, parche, corpus y complementaria, se añaden una vez instalado el software para proporcionar detalles sobre el instalador, la instalación, los parches y otros aspectos de un componente de software.

Retos de la SBOM (lista de materiales de software)

Los retos de la SBOM surgen principalmente en lo que respecta a su generación, dada su naturaleza profundamente estructurada y formal. Estos son los retos que se plantean:

• Madurez de las herramientas SBOM: Aunque las herramientas evolucionan constantemente para cumplir con los formatos y estructuras SBOM estandarizados, todavía existen algunas lagunas. Además, el manejo de estas herramientas también resulta complicado para las diferentes partes interesadas, debido a la falta de buenas interfaces, entre otros factores.
• Lenta adopción e integración: Todavía hay proveedores externos que no cumplen con el mandato de SBOM, lo que provoca un retraso en la adopción e integración de los recursos SBOM, especialmente con el software de código abierto.
• Continuidad en la generación de SBOM: Las empresas aún no han logrado que la generación de SBOM sea un proceso continuo, de modo que se produzca en diferentes etapas del SDLC. Aunque es una aspiración para la mayoría de las empresas que trabajan con SBOM, muchas de ellas aún no lo han logrado.
• Preocupaciones adicionales en materia de seguridad: Hay expertos en seguridad que también afirman que la gestión generalizada de las vulnerabilidadesno puede proteger los ecosistemas digitales de las amenazas externas. Las organizaciones deben priorizar las vulnerabilidades que desean abordar y elaborar estrategias en consecuencia. Esto es difícil de lograr cuando se trabaja con SBOM, debido a la complejidad añadida.

Prácticas recomendadas para garantizar un uso eficaz de SBOM

Generar una SBOM ya es una buena práctica. La mejor práctica sería generarla de forma coherente y a lo largo de todo el ciclo de vida del desarrollo de software (SDLC). A continuación se indican otras prácticas que pueden contribuir a ello y maximizar la utilidad de las SBOM para la seguridad de la cadena de suministro:

• Generar pronto y actualizar con regularidad: Es esencial que las SBOM se generen lo antes posible en el SDLC, de modo que todas las dependencias añadidas puedan registrarse desde el principio. Las actualizaciones periódicas de la SBOM garantizarán que todas las compilaciones y versiones de los distintos componentes de software se reflejen debidamente en la lista.
• Generación automatizada de SBOM: Dado que la compatibilidad con la automatización es una parte esencial de las SBOM, lo lógico es disponer de recursos de automatización para generarlas. La automatización también garantizaría la generación periódica de facturas a lo largo del SDLC.
• Formatos estandarizados: Formatos como SPDX o CycloneDX tienen la profundidad necesaria para capturar realmente los datos de SBOM sensibles a la seguridad. El uso de estos formatos estandarizados garantizaría la interoperabilidad y la legibilidad por máquina de la factura.
• Control de versiones: El control de versiones en las SBOM garantizará que cualquier cambio nuevo incorporado o publicado en el componente de software pueda rastrearse fácilmente para su evaluación de seguridad. Esto también hace que la SBOM sea más responsable a la hora de gestionar las dependencias.

Casos de uso de SBOM

Aunque su utilidad principal es ofrecer información crítica sobre la vulnerabilidad del software, SBOM puede adaptarse a muchos casos de uso, entre los que se incluyen:

• Seguridad del software: Las SBOM pueden ayudar a los equipos de seguridad a identificar con precisión las partes vulnerables del código del software. Los equipos pueden utilizarlas para buscar y abordar cualquier parte del software propensa a ser explotada por los ciberatacantes.

• Seguridad de la cadena de suministro: Muchas instituciones gubernamentales, incluidos los gobiernos de EE. UU. y algunos europeos, han ordenado la inclusión de SBOM en las cadenas de suministro de software. Los expertos predicen que pronto también estarán disponibles para los clientes finales.

• Facilidad de adquisición: Dada la preocupación de las empresas de todos los sectores por los incidentes de ciberseguridad, las SBOM inspiran confianza a los equipos de adquisición que buscan una solución de software. La transparencia que ofrecen ha contribuido a generar confianza entre ambas partes.

• Facilidad de desarrollo: Dado que las SBOM contienen un desglose detallado de las dependencias y relaciones entre los componentes de software, a los desarrolladores les resulta más fácil trabajar en nuevos componentes sin alterar el funcionamiento anterior.

Diferencias entre SBOM y SCA

Sin duda, la lista de materiales de software (SBOM) y el análisis de la composición del software (SCA) tienen características que se solapan y que pueden ayudar a comprender los diferentes componentes del software. Por lo tanto, una elección informada entre ambos depende del alcance del ciclo de vida del software para el que se desee utilizarlos.

Esto es lo que los líderes empresariales deben saber para tomar esa decisión:

Aspecto	SBOM	SCA
Enfoque	Enfoque dedicado a registrar componentes de software variados y generar una lista detallada.	El enfoque se centra en gestionar y analizar componentes en busca de vulnerabilidades.
Ofertas	Ofrece un inventario jerárquico de componentes, bibliotecas y dependencias.	Ofrece identificación y corrección de vulnerabilidades de seguridad debidas a componentes propensos a riesgos.
Utilidad	El alcance de la utilidad es más amplio, ya que abarca a desarrolladores, equipos de seguridad, equipos de adquisiciones, etc.	Se limita principalmente a los equipos de seguridad que necesitan herramientas SCA para abordar los componentes vulnerables.

Diferencias entre BOM y SBOM

BOM y SBOM suenan tan similares en su naturaleza que a menudo se pueden confundir entre sí. Sin embargo, ambos pertenecen a ámbitos muy distintos. Mientras que la BOM es un inventario más relevante para el ámbito de la fabricación, la SBOM tiene una función muy específica dentro de la ingeniería de software. A continuación se explica cómo los responsables de la toma de decisiones pueden diferenciar ambos conceptos:

Aspecto	Lista de materiales (BOM)	Lista de materiales de software (SBOM)
Aplicación	Más aplicable a productos físicos como hardware o electrónica.	Aplicación dedicada a productos de software y sus cadenas de suministro.
Cumplimiento normativo	Cumplimiento normativo centrado en las regulaciones de fabricación o construcción.	Cumplimiento normativo centrado en licencias de software, necesidades de seguridad, etc.
Usuarios	Fabricantes, gestores de la cadena de suministro.	Desarrolladores, equipos de seguridad y auditores de normativa.

Conclusión

Al formar parte de las regulaciones administrativas para la ciberseguridad, SBOM ya ocupa un lugar fundamental en el ciclo de vida del software. La seguridad de las cadenas de suministro de software es uno de los diversos casos de uso a los que puede servir. Con arquitecturas distribuidas, infraestructura codificada y redes extendidas, las soluciones de software ahora sirven a casos de uso empresarial más complejos que nunca. Los componentes clave y los formatos estándar de SBOM lo convierten en un poderoso aliado para frenar incidentes como los de Uber y Solarwinds.

Basándose en lo expuesto en este blog, los líderes empresariales y los expertos en seguridad pueden seguir las mejores prácticas para automatizar la generación de SBOM y aprovecharlas para la seguridad de la cadena de suministro.

SentinelOne puede ayudarle a emplear funciones como SBOM para proteger su cadena de suministro de software. Obtenga más información sobre nuestra experiencia aquí.

"

FAQs

¿Qué es un SBOM y por qué es importante?

Una lista de materiales de software, o SBOM, es un desglose detallado de los distintos componentes de software, bibliotecas, dependencias y otros elementos en forma de lista jerárquica. Es importante garantizar la visibilidad de las partes del código de software propensas a riesgos, que pueden ser explotadas para ciberataques.

¿Cómo mejora una SBOM la seguridad de la cadena de suministro de software?

Gracias a la profunda visibilidad que ofrece la SBOM, a los expertos en seguridad les resulta más fácil encontrar posibles vulnerabilidades en la cadena de suministro de software y abordarlas de manera eficaz.

¿Cuáles son los componentes clave de una SBOM?

Según las normativas administrativas, los elementos clave de una SBOM incluyen campos de datos, prácticas y procesos, y soporte de automatización.

¿Cómo pueden las organizaciones implementar una estrategia SBOM eficaz?

Para una estrategia SBOM eficaz, es esencial seguir las mejores prácticas, como la generación temprana, las actualizaciones periódicas, la generación automatizada y la integración con los procesos CI/CD.

¿Qué estándares se deben seguir al crear un SBOM?

Las tres normas que mejor funcionan con SBOM son SPDX, CycloneDC y SWID Tags.

¿Cómo puedo obtener una lista de materiales de software?

Para generar una lista de materiales de software, puede utilizar herramientas de automatización que le ayudarán con los formatos y resultados necesarios. Nuestros expertos de SentinelOne pueden ayudarle con ello.