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

Una lista de materiales de software (SBOM) es un documento que proporciona un inventario detallado de los componentes y las dependencias utilizados en un proyecto de software. También enumera todas las bibliotecas y los frameworks empleados en el software, junto con sus respectivas versiones. En el caso del software de código abierto (OSS), una SBOM puede desempeñar un papel crucial para garantizar la transparencia, la seguridad y el cumplimiento normativo.

Por qué su organización debería utilizar SBOM

El uso de una SBOM, especialmente en el software de código abierto (OSS), permite a una organización obtener visibilidad sobre los componentes y las dependencias, mejorar la gestión de riesgos y mucho más. A continuación, describimos estas ventajas.

Visibilidad de los componentes

El software de código abierto suele incorporar diversos componentes y dependencias de terceros. Una SBOM permite a los desarrolladores y usuarios conocer claramente todos los componentes utilizados en el software. Esto incluye bibliotecas y frameworks de código abierto, junto con sus versiones específicas. Esta visibilidad ayuda a comprender la composición del software, identificar posibles vulnerabilidades y realizar un seguimiento de las obligaciones de licencia asociadas a los componentes de código abierto.

Gestión de vulnerabilidades

Al igual que cualquier otro software, el software de código abierto puede ser susceptible a vulnerabilidades de seguridad. Con una SBOM, las organizaciones pueden realizar un seguimiento de las versiones de los componentes de código abierto y mantenerse informadas sobre cualquier vulnerabilidad conocida asociada a dichas versiones. Esto permite gestionar las vulnerabilidades de forma proactiva mediante la aplicación inmediata de parches o actualizaciones para mitigar y notificar cualquier problema de seguridad (véase RFC8615). Al disponer de una SBOM actualizada, las organizaciones pueden evaluar el impacto de las vulnerabilidades y adoptar las medidas adecuadas para proteger su software.

Seguridad de la cadena de suministro

En los últimos años, la seguridad de la cadena de suministro de software se ha convertido en una preocupación importante. Una SBOM contribuye a mejorar la seguridad de la cadena de suministro al aportar transparencia sobre los componentes utilizados en el software y su procedencia. También permite a las organizaciones evaluar la fiabilidad y el nivel de seguridad de los componentes de los que dependen. Con una SBOM, las organizaciones pueden identificar y mitigar los riesgos asociados a componentes comprometidos o maliciosos, reduciendo así la posibilidad de sufrir ataques a la cadena de suministro de software.

Colaboración y gestión de parches

El software de código abierto fomenta la colaboración y la participación de la comunidad. Una SBOM facilita una colaboración eficaz al proporcionar a los distintos colaboradores y partes interesadas una visión común de los componentes del software. Además, ayuda a coordinar la gestión de parches al identificar claramente los componentes que requieren actualizaciones o correcciones. La colaboración dentro de la comunidad de código abierto resulta más eficiente cuando todos los participantes pueden consultar una SBOM compartida para abordar vulnerabilidades de seguridad y otros problemas.

Cumplimiento normativo

En algunos sectores, los marcos normativos exigen que las organizaciones demuestren transparencia y control sobre los componentes de software utilizados en sus aplicaciones o sistemas. Una SBOM proporciona la documentación necesaria para cumplir estos requisitos normativos. Permite a las organizaciones demostrar la diligencia debida, la trazabilidad y el cumplimiento de la normativa pertinente, especialmente en lo que respecta a la seguridad y las licencias del software de código abierto.

Cumplimiento de licencias

El software de código abierto suele regirse por licencias específicas que determinan cómo puede utilizarse, modificarse y distribuirse. Una SBOM ofrece una visión completa de todos los componentes de código abierto y sus correspondientes licencias. Esto ayuda a las organizaciones a garantizar el cumplimiento de los términos de las licencias del software de código abierto que utilizan. Al conocer las obligaciones de las licencias, las organizaciones pueden tomar decisiones fundamentadas sobre la distribución y el uso de su software, al tiempo que evitan posibles problemas legales o de cumplimiento normativo.

Requisitos de la SBOM en sectores altamente regulados

Varios gobiernos y organizaciones de sectores altamente regulados, como la banca y la sanidad, promueven el uso de las SBOM o se plantean exigirlas, ya sea internamente o a sus proveedores.

Ejemplos de sectores que utilizan SBOM

Sector público – Estados Unidos, la Unión Europea, el Reino Unido y Japón se encuentran entre los numerosos países que utilizan, regulan o recomiendan el uso de las SBOM.
Tecnología – Grandes empresas tecnológicas como Google, Microsoft e IBM están a la vanguardia al implementar SBOM en sus propios procesos de desarrollo de software y contribuir a proyectos como Software Package Data Exchange (SPDX), OWASP, así como al publicar como código abierto una herramienta de generación de SBOM.
Automoción – Varias grandes empresas automovilísticas, como Ford y General Motors, están implementando SBOM y animando a sus proveedores a proporcionar SBOM para los componentes y el software utilizados en los sistemas de automoción.
Sanidad – Los fabricantes de productos sanitarios del mercado estadounidense utilizan ahora las SBOM para cumplir una normativa de 2022 de la Administración de Alimentos y Medicamentos de Estados Unidos.

¿Quién forma parte de un equipo de SBOM?

La elaboración de una SBOM requiere la colaboración y participación de diversas partes interesadas a lo largo de toda la cadena de suministro de software. Al implicar a estas partes interesadas y fomentar la colaboración entre ellas, las organizaciones pueden crear una SBOM sólida y fiable que recopile la información necesaria sobre los componentes de software, refuerce la seguridad de la cadena de suministro y facilite la gestión de riesgos y el cumplimiento normativo.

Estas son algunas de las personas o funciones clave que deberían participar en el proceso:

Equipo de desarrollo – El equipo de desarrollo, incluidos los ingenieros de software y los desarrolladores, desempeña un papel fundamental en la identificación y documentación de los componentes de software utilizados en el proyecto. Es responsable de proporcionar información precisa sobre las dependencias, las versiones y el origen de los componentes de software que utiliza.
Responsables de proyecto – Los responsables de proyecto supervisan el proceso general de desarrollo de software y deben participar en la elaboración de una SBOM. Pueden coordinarse con el equipo de desarrollo para garantizar que la información necesaria se recopile y documente en la SBOM. Los responsables de proyecto también desempeñan un papel importante a la hora de garantizar el cumplimiento de los requisitos de la SBOM y de integrarla en el flujo de trabajo del proyecto.
Equipo de seguridad – El equipo de seguridad, incluidos los analistas y especialistas en seguridad, desempeña un papel fundamental en la evaluación y gestión de los riesgos de seguridad asociados a los componentes de software. Puede aportar información sobre vulnerabilidades y problemas de seguridad conocidos relacionados con los componentes incluidos en su SBOM. Su experiencia ayuda a identificar posibles riesgos de seguridad y a priorizar las medidas correctivas.
Equipo de compras – El equipo de compras, o las personas responsables de adquirir componentes de software, desempeña un papel fundamental en la elaboración de una SBOM. Puede proporcionar información sobre el origen y los detalles de las licencias de los componentes obtenidos de fuentes externas. La colaboración con el equipo de compras garantiza un seguimiento y una verificación precisos de los componentes de software dentro de la cadena de suministro.
Equipo de operaciones – El equipo de operaciones suele ser responsable de desplegar y mantener el software. A la hora de elaborar una SBOM, puede aportar información valiosa sobre el entorno de ejecución, las configuraciones de despliegue y cualquier componente de software adicional incorporado durante la fase operativa. Sus conocimientos permiten garantizar que la SBOM sea completa y esté actualizada.
Expertos jurídicos y de cumplimiento normativo – Los profesionales jurídicos y de cumplimiento normativo son partes interesadas esenciales en la elaboración de una SBOM, especialmente en lo relativo a las licencias y la propiedad intelectual. Pueden ofrecer orientación sobre el cumplimiento de las licencias y garantizar que su SBOM se ajuste a todos los requisitos o restricciones legales asociados a los componentes de software.
Proveedores y socios externos – Si el proyecto de software incorpora componentes o servicios de proveedores o socios externos, es fundamental involucrarlos en el proceso de elaboración de la SBOM. Pueden proporcionar la información necesaria sobre sus productos y servicios, incluidas las dependencias, las versiones y las vulnerabilidades. La colaboración con las partes interesadas externas ayuda a garantizar que la SBOM sea completa y precisa.

Cómo crear una SBOM

Las organizaciones deberían aspirar a crear una SBOM que ofrezca una visión completa de los componentes de software, sus orígenes, dependencias y la información de seguridad asociada. Esto permite gestionar mejor los riesgos de la cadena de suministro de software y mejora la seguridad general del software.

Estos son los pasos clave para crear una SBOM:

Identifique e inventaríe los componentes: Empiece por identificar todos los componentes de software utilizados en su proyecto, incluidos tanto los componentes propietarios como los de código abierto. Cree una lista de inventario que incluya información como el nombre, la versión y el origen de cada componente.
Determinar el origen de los componentes: Para cada componente, determine su origen, ya sea propietario, de código abierto o una combinación de ambos. Este paso ayuda a evaluar las posibles vulnerabilidades de seguridad asociadas a los distintos componentes.
Documentar las dependencias: Documente las dependencias entre los componentes, incluidas las bibliotecas o los frameworks utilizados. Esto ayuda a comprender las relaciones entre los distintos componentes y garantiza que se tengan en cuenta todas las dependencias.
Recopilar metadatos: Recopile los metadatos de cada componente, como la información sobre licencias, las vulnerabilidades conocidas y las fechas de lanzamiento. Esta información es fundamental para realizar un seguimiento de los aspectos de seguridad y cumplimiento normativo de los componentes de software.
Automatice la generación de la SBOM: Para agilizar el proceso, considere la posibilidad de automatizar la generación de la SBOM mediante herramientas especializadas. Estas herramientas pueden analizar su proyecto de software, identificar los componentes y recopilar automáticamente la información necesaria.
Mantén tu SBOM actualizado: A medida que evoluciona tu proyecto de software, es fundamental mantener actualizado el SBOM. Revisa y actualiza periódicamente el inventario, el origen de los componentes, las dependencias y los metadatos a medida que se produzcan cambios.
Comparta y utilice su SBOM: Comparta su SBOM con las partes interesadas pertinentes de su cadena de suministro de software, como proveedores, clientes y auditores. Esto fomenta la transparencia, permite evaluar mejor los riesgos y ayuda a identificar y abordar las vulnerabilidades.
Supervise y gestiona las vulnerabilidades: Supervisa continuamente la aparición de nuevas vulnerabilidades y actualizaciones de seguridad relacionadas con los componentes de tu SBOM. Mantente al día sobre los últimos parches de seguridad y corrige rápidamente cualquier vulnerabilidad para preservar la seguridad de tu software.

Siete formas en que una SBOM puede no cumplir su cometido

Hay varias formas en las que una SBOM puede fallar o no cumplir plenamente su propósito. Abordar estos retos y garantizar que su SBOM sea precisa, completa y esté actualizada puede ayudar a reducir el riesgo de que falle.

Estas son algunas causas habituales de fallo que se corresponden con las prácticas recomendadas para crear una SBOM:

Inventario incompleto o inexacto: Si su SBOM no recoge con precisión todos los componentes de software utilizados en un proyecto o contiene información incompleta, pueden surgir puntos ciegos y lagunas en la comprensión de la cadena de suministro de software. Un inventario incompleto o inexacto puede hacer que se pasen por alto vulnerabilidades o dependencias, lo que reduce la eficacia de su SBOM.
Falta de visibilidad de los componentes: Si su SBOM no ofrece una visibilidad clara sobre el origen, las versiones y las dependencias de los componentes de software, resulta difícil evaluar y gestionar eficazmente los riesgos asociados. Sin una visibilidad completa, es complicado realizar un seguimiento de las vulnerabilidades, identificar las actualizaciones de parches y garantizar el cumplimiento de los requisitos de las licencias.
Procesos manuales y obsoletos: Depender de procesos manuales para crear y mantener una SBOM puede generar ineficiencias y errores. Si la SBOM no se actualiza periódicamente para reflejar los cambios en el proyecto de software, queda obsoleta rápidamente y pierde su valor como referencia fiable en materia de seguridad y cumplimiento normativo.
Metadatos y contexto insuficientes: Una SBOM debe proporcionar algo más que una lista de componentes de software; debe incluir metadatos relevantes, como información sobre licencias, vulnerabilidades conocidas y fechas de lanzamiento. Si este contexto adicional no está disponible o está incompleto, resulta más difícil evaluar los riesgos con precisión y tomar decisiones fundamentadas.
Falta de colaboración entre las partes interesadas: La colaboración y el intercambio de información entre las partes interesadas de la cadena de suministro de software son fundamentales para utilizar eficazmente una SBOM. Si existe una falta de cooperación o reticencia a compartir información de la SBOM, resulta difícil identificar y abordar las vulnerabilidades de forma conjunta, lo que pone en riesgo la seguridad general del software.
Herramientas y automatización limitadas: La creación y el mantenimiento manuales de una SBOM pueden requerir mucho tiempo y ser propensos a errores. Sin las herramientas y la automatización adecuadas, resulta difícil generar, actualizar y gestionar la SBOM de forma eficiente. La falta de automatización también puede provocar retrasos en la identificación de nuevas vulnerabilidades o dependencias.
Supervisión inadecuada de vulnerabilidades: Una SBOM debe complementarse con un proceso sólido de supervisión de vulnerabilidades. Si no se realiza un seguimiento periódico de las nuevas vulnerabilidades y actualizaciones de seguridad asociadas a los componentes de software, los posibles riesgos pueden pasar desapercibidos y dejar el software expuesto a vulnerabilidades conocidas.

Resumen

En general, una SBOM es una herramienta valiosa para gestionar las complejidades del software de código abierto. Fomenta la transparencia, la seguridad, el cumplimiento normativo y la colaboración dentro del ecosistema de código abierto. Al proporcionar un inventario detallado de los componentes de software, sus versiones y la información sobre las licencias asociadas, una SBOM permite a las organizaciones tomar decisiones fundamentadas, gestionar los riesgos y garantizar la integridad y la seguridad de sus proyectos de software.

Contenido relacionado