Una lista de materiales de software (SBOM) es una lista estructurada de componentes y dependencias que conforman una aplicación o sistema de software. Las SBOM incluyen información como los nombres y versiones de todos los componentes, las relaciones entre ellos y su información sobre licencias y vulnerabilidades.
La evolución de los SBOM se remonta a la creciente complejidad de las aplicaciones de software y a la creciente preocupación por la seguridad de la cadena de suministro de software. Por ejemplo, a medida que las aplicaciones de software se han vuelto más complejas y dependientes de componentes de terceros, a los desarrolladores y equipos de seguridad les ha resultado más difícil rastrear y gestionar las dependencias entre los componentes.
Varios incidentes de seguridad de gran repercusión, como el hackeo de SolarWinds, han puesto de relieve la necesidad de una mayor visibilidad y responsabilidad en las cadenas de suministro de software. Esto ha provocado un mayor interés y adopción de las SBOM como medio para mejorar la seguridad del software. De hecho, el Gobierno de los Estados Unidos está impulsando las SBOM, que podrían convertirse en un elemento fundamental de la supervisión y la notificación de la gestión de riesgos de terceros en un futuro próximo.
Esta publicación examina cómo se aplican las SBOM a la gestión de riesgos de terceros, revisa los recientes esfuerzos de estandarización y ofrece recomendaciones sobre las mejores prácticas para empezar.
Cómo se aplican los SBOM a la gestión de riesgos de terceros
Las SBOM tienen varias aplicaciones en la gestión de terceros, entre ellas:
- Gestión de riesgos: las SBOM pueden utilizarse para identificar y evaluar los riesgos asociados a los componentes de terceros en una aplicación de software. Mediante el análisis de la SBOM, los equipos de seguridad pueden identificar vulnerabilidades y determinar si los componentes están actualizados y correctamente configurados.
- Cumplimiento normativo: Muchos sectores, como el sanitario y el financiero, tienen requisitos de cumplimiento muy estrictos que incluyen componentes de software de terceros. Las SBOM se pueden usar para garantizar que todos los componentes cumplan estos requisitos y tengan las licencias adecuadas.
- Gestión de la cadena de suministro: Las SBOM pueden utilizarse para gestionar la cadena de suministro de software mediante la identificación del origen y la propiedad de cada componente. Esto puede ayudar a las organizaciones a garantizar que solo utilizan componentes de fuentes fiables y a realizar un seguimiento de cualquier cambio o actualización de los componentes.
A medida que la complejidad de las aplicaciones de software sigue aumentando, es esencial que las organizaciones comprendan claramente sus componentes de software y los riesgos asociados a ellos. Las SBOM proporcionan una forma estructurada de lograr esta visibilidad y responsabilidad.
Iniciativas con requisitos SBOM
Aunque las SBOM existen desde hace tiempo, su adopción ha crecido a medida que las amenazas y las regulaciones en materia de ciberseguridad han exigido enfoques más proactivos para gestionar los riesgos de terceros. El futuro de las SBOM en la gestión de riesgos de terceros parece prometedor, ya que cada vez más organizaciones reconocen la importancia de gestionar los riesgos de la cadena de suministro de software. De hecho, ya hay iniciativas en marcha para exigir SBOM para determinados tipos de software. He aquí dos ejemplos:
- Administración Nacional de Telecomunicaciones e Información (NTIA): La Administración Nacional de Telecomunicaciones e Información (NTIA) de los Estados Unidos ha liderado los esfuerzos para desarrollar un formato SBOM estandarizado, que ha ganado adeptos entre los líderes del sector y los organismos reguladores. Además, la Agencia de Seguridad Cibernética y de Infraestructuras (CISA) ha publicado recientemente una guía en la que recomienda a las organizaciones incorporar los SBOM como parte de sus prácticas de gestión de riesgos en la cadena de suministro de software, haciendo referencia a las recomendaciones de la NTIA.
- Orden ejecutiva sobre la mejora de la ciberseguridad nacional: el presidente de los Estados Unidos , Joe Biden, ha emitido una orden ejecutiva y ha publicado un informe actualizado sobre la estrategia de ciberseguridad que exigirá SBOM para todo el software vendido al Gobierno.
Formatos y estándares SBOM
Uno de los retos que plantea la adopción de las SBOM es la falta de estandarización. Actualmente existen varios estándares industriales diferentes para las SBOM.
- CycloneDX SBOM: Uno de los estándares más utilizados y aceptados es el formato CycloneDX SBOM, un estándar abierto desarrollado por el proyecto CycloneDX. El formato CycloneDX está diseñado para ser fácil de usar e implementar, e incluye compatibilidad con una amplia gama de componentes de software y gestores de paquetes.
- SPDX: Otro formato SBOM muy utilizado es SPDX (Software Package Data Exchange), mantenido por el grupo de trabajo SPDX de la Fundación Linux. SPDX es un estándar abierto para describir paquetes de software y sus metadatos asociados, incluida la información sobre licencias y las declaraciones de derechos de autor.
- Etiquetas SWID: Las etiquetas SWID (etiquetas de identificación de software) son una forma estandarizada de identificar componentes de software y sus metadatos asociados.
- BOMXML: BOMXML es un formato basado en XML para describir componentes de software y sus relaciones.
En general, la elección del formato SBOM puede depender de las necesidades y requisitos específicos de la organización o industria que lo utilice, así como de las herramientas y sistemas que se utilicen para generar y consumir los datos SBOM. Esto aumenta la complejidad para los equipos y tecnologías de riesgo de terceros, ya que pueden necesitar consumir, interpretar y analizar múltiples formatos.
Cómo incluir SBOM en su programa de gestión de riesgos de terceros
Independientemente de las complejidades que ello implique, se prevé que el uso de SBOM aumente. A medida que su uso se generalice, es probable que se conviertan en una parte estándar de las prácticas de gestión de riesgos de terceros. Las organizaciones podrán utilizar las SBOM para identificar vulnerabilidades en el software de terceros y tomar medidas proactivas para mitigar esos riesgos. Además, es posible que los organismos reguladores exijan a las organizaciones que proporcionen SBOM como parte de sus requisitos de cumplimiento. A continuación se ofrecen algunas recomendaciones para considerar la SBOM como un componente de la diligencia debida de terceros:
- Exigir a los proveedores que proporcionen SBOM: como parte del proceso de diligencia debida, exija a los proveedores que proporcionen SBOM actualizadas para sus productos de software. Esto le ayudará a identificar cualquier posible vulnerabilidad o problema de licencia que pueda afectar a la seguridad y el cumplimiento normativo de su organización.
- Evaluar el riesgo de terceros: el uso de una SBOM para evaluar los riesgos asociados al software de terceros le ayudará a determinar qué componentes pueden requerir un examen más detallado o medidas de mitigación adicionales.
- Evaluar el cumplimiento de las licencias: Las SBOM pueden utilizarse para evaluar el cumplimiento de los requisitos de licencia de los componentes de software de terceros y evitar infracciones de licencia.
- Supervisar las vulnerabilidades: utilice una SBOM para supervisar las vulnerabilidades en los componentes de software de terceros, identificar cualquier riesgo potencial para la seguridad y tomar medidas proactivas para mitigar los riesgos.
- Desarrollar planes de mitigación: los SBOM pueden ayudarle a desarrollar planes de mitigación de riesgos y a abordar posibles problemas de seguridad o cumplimiento antes de que se conviertan en un problema.
- Mantenga actualizados los SBOM: asegúrese de que los SBOM se mantengan actualizados a medida que se añaden nuevos componentes de software y se actualizan los componentes existentes. Esto le ayudará a mantener una visión precisa y completa de las dependencias de software de su organización.
Al incorporar estas recomendaciones en su proceso de diligencia debida con terceros, puede garantizar que su organización gestione de forma eficaz los riesgos asociados a los componentes de software de terceros.
En Prevalent, admitimos archivos SBOM como prueba dentro del proceso de diligencia debida. Para obtener más información sobre cómo podemos ayudarle a incorporar SBOM en la estrategia de su programa TPRM, solicite una demostración hoy mismo.
Nota de la Redacción: Este artículo se publicó originalmente en Prevalent.net. En octubre de 2024, Mitratech adquirió la empresa de gestión de riesgos de terceros basada en IA, Prevalent. El contenido se ha actualizado desde entonces para incluir información alineada con nuestras ofertas de productos, cambios normativos y cumplimiento.
