En los últimos años, la lista de materiales del software (SBOM) se ha convertido en un elemento clave de la seguridad del software y la gestión de riesgos de la cadena de suministro de software.
Hablamos con Tim Mackey, jefe de estrategia de riesgo de la cadena de suministro de software en Synopsys para obtener más información sobre los beneficios y desafíos de los SBOM.
BN: ¿Cuál fue la conclusión clave que surgió como resultado de la vulnerabilidad de Log4shell?
TM: La experiencia de Log4Shell destacó que el uso de código abierto era generalizado dentro de las organizaciones. Incluso se descubrió que el software comercial tiene componentes de código abierto como dependencias. Esto puso de relieve que los proyectos de código abierto son creados y mantenidos por voluntarios externos, y no por sus propios empleados o proveedores comerciales externos. Esto significaba que TI carecía de controles sobre el uso de software de código abierto dentro del software comercial, incluso si tenían procesos maduros de gobierno de código abierto para el software de código abierto que descargaban y usaban directamente, o que se usaba dentro de sus esfuerzos de desarrollo de software personalizado.
BN: ¿Qué deben entender las organizaciones sobre el código abierto para estar mejor preparadas para enfrentar los desafíos únicos que trae consigo?
TM: El primer paso es a menudo simplemente reconoce que está utilizando código abierto y desde allí puede definir un flujo de trabajo de gobernanza viable. Dado que los equipos de código abierto no saben quién descargó su código, no tiene un mecanismo de inserción para las actualizaciones; Tienes un mecanismo de tracción. Entonces, cuando un proyecto se abandona efectivamente, o al final de su vida útil, nos encantaría que los mantenedores fueran y dijeran:”Oye, he terminado con este proyecto”, y le pongan un pequeño aviso que diga no habrá nuevas actualizaciones, pero eso no suele suceder.
Ahora, ser capaz de identificar proyectos’abandonados’versus’terminados’es un problema aparte. No puede tomar esa determinación si no está comprometido con el proyecto, así que si no sabía que estaba usando un proyecto, vaya y comience a hacer estas preguntas. Y esa es realmente la gran primera pieza del rompecabezas: aceptar que tiene código abierto, aceptar que se administra de manera diferente y poner en marcha un proceso que incluye estar comprometido con esos proyectos.
Donde las cosas se vuelven particularmente desafiantes es cuando estás, digamos, a tres o cuatro niveles de profundidad en la dependencia o en la cadena de proveedores que no necesariamente sabes que tienes un código fuente abierto ejecutándose. Esa es una de las lecciones de toda la experiencia de Log4j, la gente no sabía que existía esta cosa llamada Log4j antes de que ocurriera el problema.
BN: ¿Qué es exactamente un SBOM?
TM: Un SBOM es fundamentalmente un archivo que enumera las bibliotecas utilizadas por una aplicación. Es un componente clave de un plan de gobierno que abarca no solo el uso de código abierto en una cadena de suministro de software, sino que también se convierte en un punto de anclaje para otros elementos operativos. El elemento operativo más común que se discute hoy es el uso de SBOM para comunicar la exposición a vulnerabilidades dentro de los componentes en la cadena de suministro de software para la aplicación dada.
BN: ¿Es un SBOM por sí solo suficiente para mitigar riesgos de seguridad y licencias del código abierto?
TM: No. Debido a que se presentó un SBOM en una Orden Ejecutiva, se ha prestado mucha atención a’Necesito ir y tener un SBOM.’A efectos prácticos, muchas organizaciones hoy en día están creando SBOM y es simplemente una lista de materiales que dice:”Tengo estos componentes que provienen de este lugar, y esta es su versión”.
Es en realidad una cosa estática. Representa el aspecto que tenía esa pieza de software cuando se envió. Es fantástico en ese sentido, pero no te dirá si es más o menos seguro que otra cosa. Le está diciendo estrictamente cómo se ve esa lista de ingredientes para esa pieza de software en particular, y ahí es donde la gente se engaña un poco. El SBOM del que todo el mundo habla no es este unicornio mágico: es parte de un flujo de trabajo que debe implementarse dentro de las empresas.
El’SB’en SBOM no significa Silver Bullet.
p>
El problema es que los datos de SBOM deben ingresar en un flujo de trabajo. Las personas que están en el extremo receptor del SBOM podrían estar diciendo:”Aquí tengo este archivo con el que no sé qué hacer”, y eso se refiere a un flujo de trabajo, un conjunto de procesos que las organizaciones necesitan averiguarlo.
En otras palabras, el conocimiento proporcionado por los SBOM es obviamente valioso, pero si su organización no tiene un proceso para consumirlo, entonces hay un beneficio mínimo de tener un SBOM y la información de vulnerabilidad asociada.. Esta falta de proceso es el mayor desafío, ya que si bien los equipos de compras pueden solicitar SBOM de todos sus proveedores, si no hay un proceso bien definido para actuar sobre la información en el SBOM, entonces todo lo que sucede es que tiene ahora tengo un archivo más en un directorio.
BN: ¿Cómo sería un proceso exitoso y bien definido para obtener valor de los SBOM?
TM: Todas las organizaciones tienen un departamento de TI que es responsable de mantener los parches en el software que está dentro de esa organización. Todo el software está construido a partir de componentes. Sabemos por el informe Synopsys OSSRA que el uso de código abierto dentro del software comercial promedia el 78 por ciento. Entonces, sabe que habrá componentes de código abierto y que necesitarán ser actualizados. El SBOM comunica esa información si está adjunta al activo que está administrando TI.
Ahora, cuando llega el momento en que hay una nueva divulgación de vulnerabilidad, TI está en posición de ir y consultar ese sistema de administración de SBOM. y decir:”Ajá, tengo esto, pero ¿de dónde viene mi parche?”El parche proviene de la información de procedencia de la SBOM; esa es la función de una SBOM. No es para decirle que tiene una nueva vulnerabilidad: es un documento que describe exactamente qué hay en ese artefacto que está tratando de ejecutar, y ahora puede hacer lo correcto si tiene ese flujo de trabajo.
BN: ¿Qué requisitos debe cumplir un SBOM?
TM: Para que sea útil, un SBOM debe ser preciso y completo, y esos son dos problemas diferentes pero que resuelven uno, depende de resolver el otro.
Para comenzar, todas las bibliotecas externas empaquetadas dentro de una aplicación deben registrarse para que un SBOM esté completo, incluido el software de código abierto, las bibliotecas comerciales de terceros y cualquier software introducido a través de un contrato de terceros. Idealmente, el SBOM se extraería del código fuente de una aplicación, aunque esto puede ser un proceso difícil dependiendo de cómo se defina el proceso de compilación de las aplicaciones. Por ejemplo, es posible que necesite dos SBOM diferentes al compilar una aplicación para dos plataformas diferentes; uno para Windows y otro para Linux.
Igualmente, es importante que los componentes se identifiquen con precisión, reconociendo todo desde su punto de origen hasta la versión del mismo. Un SBOM de origen, que se extrae del código fuente de la aplicación, es más preciso, pero también hay SBOM de terceros. En este caso, se escanea la aplicación y no el código fuente. Esto podría dar como resultado que falte información ya que no tiene la capacidad de determinar la versión precisa de la biblioteca; por lo tanto, hacer que este método sea adecuado solo si los SBOM de origen no están disponibles o como un medio para verificar dos veces el SBOM de origen.
BN: ¿Qué ve para el futuro de los SBOM en abordar las vulnerabilidades de código abierto y los riesgos generales de la cadena de suministro de software?
TM: Estamos muy temprano en la era SBOM. La mayoría de los proveedores todavía están trabajando para crear SBOM y eso continuará en el futuro previsible. Sin embargo, si bien un proveedor que puede proporcionar un SBOM es un indicador de la perspicacia en seguridad de código abierto, no es el único indicador. Es importante destacar que si una organización solicita un SBOM de un proveedor pero no tiene un flujo de trabajo para procesar ese SBOM y obtener valor de él, entonces hacer que un proveedor proporcione SBOM agrega costos sin beneficio.
Curiosamente, muchos han fallado para notar que los casos de uso de seguridad para SBOM a menudo se alinean con lo que ya proporcionan las soluciones de análisis de composición de software (SCA). Los SBOM son más útiles como parte de una estrategia general de mitigación de riesgos. Esto implica que existen procesos para medir el riesgo transmitido a través de un SBOM y luego algún proceso para mitigar ese riesgo.
Crédito de la imagen: Momius/depositphotos.com