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 listas de materiales incluyen información como los nombres y versiones de todos los componentes, las relaciones entre ellos y la información sobre licencias y vulnerabilidades.
La evolución de los SBOM se debe a la creciente complejidad de las aplicaciones informáticas y a la preocupación cada vez mayor por la seguridad de la cadena de suministro de software. Por ejemplo, a medida que las aplicaciones informáticas se han vuelto más complejas y dependen de componentes de terceros, a los desarrolladores y a los 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 pirateo de SolarWinds, han puesto de relieve la necesidad de una mayor visibilidad y responsabilidad en las cadenas de suministro de software. Esto ha llevado a un mayor interés y adopción de los SBOM como medio para mejorar la seguridad del software. De hecho, el gobierno de EE.UU. está impulsando los SBOM, y en un futuro próximo podrían convertirse en un elemento principal de supervisión e información de la gestión de riesgos de terceros.
Este post examina cómo se aplican los SBOM a la gestión de riesgos de terceros, revisa los recientes esfuerzos de normalización y ofrece recomendaciones de mejores prácticas para empezar.
Aplicación de los SBOM a la gestión de riesgos de terceros
Los SBOM tienen varias aplicaciones en la gestión de terceros, entre ellas:
- Gestión de riesgos: Los SBOM pueden utilizarse para identificar y evaluar los riesgos asociados a los componentes de terceros en una aplicación de software. Analizando el SBOM, los equipos de seguridad pueden identificar vulnerabilidades y determinar si los componentes están actualizados y correctamente configurados.
- Cumplimiento: Muchos sectores, como la sanidad y los servicios financieros, tienen estrictos requisitos de conformidad que incluyen componentes de software de terceros. Los SBOM pueden utilizarse para garantizar que todos los componentes cumplen estos requisitos y disponen de las licencias adecuadas.
- Gestión de la cadena de suministro: Los SBOM pueden utilizarse para gestionar la cadena de suministro de software identificando el origen y la propiedad de cada componente. Esto puede ayudar a las organizaciones a asegurarse de que solo utilizan componentes de fuentes fiables y a realizar un seguimiento de cualquier cambio o actualización de los componentes.
A medida que aumenta la complejidad de las aplicaciones de software, es esencial que las organizaciones conozcan claramente sus componentes de software y los riesgos asociados. Los SBOM ofrecen una forma estructurada de lograr esta visibilidad y responsabilidad.
Iniciativas con requisitos SBOM
Aunque los SBOM existen desde hace algún tiempo, su adopción ha crecido a medida que las amenazas a la ciberseguridad y las normativas han requerido enfoques más proactivos para gestionar el riesgo de terceros. El futuro de los SBOM en la gestión de riesgos de terceros parece prometedor a medida que más organizaciones reconocen la importancia de gestionar el riesgo de la cadena de suministro de software. De hecho, ya hay iniciativas en marcha para exigir SBOM para ciertos 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 Estados Unidos ha liderado los esfuerzos para desarrollar un formato estandarizado de SBOM, que ha ganado adeptos entre los líderes de la industria y los reguladores. Además, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) publicó recientemente una guía que recomienda a las organizaciones incorporar los SBOM como parte de sus prácticas de gestión de riesgos de la cadena de suministro de software, haciendo referencia a las recomendaciones de la NTIA.
- Orden ejecutiva para mejorar la ciberseguridad de la nación: El Presidente de EE.UU. Biden ha emitido una Orden Ejecutiva y ha publicado un resumen actualizado de la estrategia de ciberseguridad que requeriría SBOMs para todo el software vendido al gobierno.
Formatos y normas SBOM
Uno de los problemas que plantea la adopción de los SBOM es la falta de normalización. En la actualidad, existen varias normas industriales para los SBOM.
- CycloneDX SBOM: uno de los estándares más utilizados y aceptados es el formato CycloneDX SBOM, que es 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 soporte para 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, incluyendo información sobre licencias y declaraciones de copyright.
- Etiquetas SWID: Las etiquetas SWID (Software Identification Tags) 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 empleen para generar y consumir los datos SBOM. Esto aumenta la complejidad para los equipos y tecnologías de riesgos de terceros, ya que pueden necesitar consumir, interpretar y analizar múltiples formatos.
Cómo incluir el SBOM en su programa de gestión de riesgos de terceros
Independientemente de las complejidades que entrañan, se espera que aumente el uso de los SBOM. 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 los SBOM para identificar vulnerabilidades en el software de terceros y tomar medidas proactivas para mitigar esos riesgos. Además, los reguladores pueden exigir a las organizaciones que proporcionen SBOM como parte de sus requisitos de cumplimiento. He aquí algunas recomendaciones para considerar el SBOM como un componente de la diligencia debida de terceros:
- Exigir a los proveedores que proporcionen listas de materiales de base: Como parte del proceso de diligencia debida, exija a los proveedores que proporcionen listas de materiales actualizadas para sus productos de software. Esto le ayudará a identificar cualquier vulnerabilidad potencial o problemas de licencia que puedan afectar a la seguridad y el cumplimiento de su organización.
- Evaluar el riesgo de terceros: El uso de un SBOM para evaluar los riesgos asociados con el software de terceros le ayudará a determinar qué componentes pueden requerir un escrutinio adicional o medidas de mitigación.
- Evaluar el cumplimiento de licencias: Los SBOM pueden aprovecharse para evaluar la conformidad de los componentes de software de terceros con los requisitos de licencia y evitar infracciones de licencia.
- Supervise las vulnerabilidades: Utilice un SBOM para supervisar las vulnerabilidades de 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.
- Mantener actualizados los SBOM: Asegúrese de que los SBOM se mantienen actualizados a medida que se añaden nuevos componentes de software y se actualizan los 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 a su proceso de diligencia debida de terceros, puede garantizar que su organización pueda gestionar eficazmente los riesgos asociados a los componentes de software de terceros.
En Prevalent, respaldamos los 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 su estrategia de 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.
