SBOM – SB no significa Silver Bullet

Las listas de materiales de software (SBOM) son como etiquetas de ingredientes en los comestibles. Son fundamentales para la seguridad y la salud del consumidor, están algo estandarizados, pero hay mucho más entusiasmo en el cultivo o la producción del alimento que en la etiqueta.

¿Qué es un SBOM?

¿Qué es un SBOM? En resumen, es una forma de decirle a otra parte todo el software utilizado en la pila que conforma una aplicación. Uno de los beneficios de un SBOM es que si surge una vulnerabilidad, usted sabe lo que contiene. Puede determinar fácilmente si es vulnerable y dónde. Dado que el software moderno se basa en software ya escrito (no tiene sentido reconstruir la rueda), es importante no perder todos los componentes en la mezcla. No es evidente qué utiliza ningún software en particular. Entonces, si hay una vulnerabilidad para el software A, debe saber si tengo ese software en algún lugar de mi ecosistema y, de ser así, dónde. Luego puede tomar medidas correctivas si es necesario. No puedo elogiar la analogía de la etiqueta de los alimentos utilizada en mi introducción. Lo escuché de Allan Friedman, asesor sénior y estratega de la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) y un defensor clave de SBOM, cuando habló con Kate Stewart, vicepresidenta de Confiable Embedded Systems, en la conferencia RSA 2022. la Fundación Linux. Allan señaló que las etiquetas de los alimentos solo brindan información. El consumidor debe leerlos y comprenderlos y tomar las medidas adecuadas. Por ejemplo, si son alérgicos a los cacahuetes, pueden mirar la etiqueta de ingredientes y determinar si el alimento es seguro para comer. Los SBOM son similares: le dicen a una persona qué software se está utilizando como «ingrediente» para que alguien pueda determinar si necesita tomar medidas si surge una vulnerabilidad. No es una panacea, pero es una herramienta importante. Sin SBOM, nadie puede rastrear qué «ingredientes» hay en sus aplicaciones de software.

SBOM y la cadena de suministro de software

Las cadenas de suministro afectan nuestras vidas más que limitar la disponibilidad de bienes de consumo. Las cadenas de suministro de software ahora son inmensamente más complicadas, ya que el software se construye con componentes ya instalados. Esto hace que el software sea mejor, más efectivo, más potente, etc. Pero también conlleva riesgos a medida que más y más partes trabajan con un software determinado. Al igual que nuestro mundo se ha vuelto tan interdependiente, también lo ha hecho nuestro software. Comprender qué hay en la cadena de suministro de nuestro software nos ayuda a asegurarlo de manera efectiva. Cuando surge un nuevo riesgo, sabemos qué hacer.

SBOM y seguridad del software

Los SBOM se reconocen cada vez más como un pilar clave en cualquier plan integral de seguridad de software. Una encuesta global realizada por Linux Foundation en el tercer trimestre de 2021 encontró que el 78% de las organizaciones que respondieron planean usar SBOM en 2022. Además, el Plan de Movilización de Seguridad de Software de Código Abierto recientemente publicado recomienda que los SBOM sean universales, y la Orden Ejecutiva de los EE. Y, como señala Allan en su presentación, «Compramos todo». La EO ofrece un buen resumen de los SBOM y sus beneficios: El término «Lista de materiales de software» o «SBOM» significa un registro formal que detalla los detalles y Las relaciones de la cadena de suministro contienen varios componentes utilizados en la creación de software. Los desarrolladores y proveedores de software a menudo crean productos ensamblando componentes de software comerciales y de código abierto existentes. El SBOM enumera estos componentes en un producto. Es análogo a una lista de ingredientes en los envases de alimentos. Un SBOM es útil para quienes desarrollan o fabrican software, quienes seleccionan o compran software y quienes operan software. Los desarrolladores suelen utilizar componentes de software de código abierto y de terceros disponibles para crear un producto. Con un SBOM, el constructor puede garantizar que estos componentes estén actualizados y reaccionen rápidamente ante nuevas vulnerabilidades. Los compradores pueden usar un SBOM para realizar un análisis de vulnerabilidad o licencia, los cuales pueden usarse para evaluar el riesgo de un producto. Cualquiera que opere un software puede usar SBOM para determinar rápida y fácilmente si está expuesto a un riesgo potencial de una vulnerabilidad recién descubierta. Un formato SBOM legible por máquina ampliamente utilizado permite mayores beneficios a través de la automatización y la integración de herramientas. Los SBOM ganan valor cuando se almacenan juntos en un repositorio que otras aplicaciones y sistemas pueden consultar fácilmente. Comprender la cadena de suministro de software, obtener un SBOM y usarlo para analizar vulnerabilidades conocidas es fundamental para la gestión de riesgos. Allan y Kate dedicaron tiempo en su presentación a discutir el estado actual de los SBOM, los desafíos, los beneficios, las herramientas disponibles para crear y compartir SBOM, qué es un SBOM mínimo, los estándares que se están desarrollando para automatizarlos por completo y más para discutir. Busque algunas futuras publicaciones de blog de LF que cubran esto. Pero hay cosas que puedes hacer ahora.

¿Qué pueden hacer usted y su organización ahora?

Allan y Kate han descrito varias cosas que usted y su organización pueden hacer ahora. Comience en su organización: La próxima semana: Comprenda los orígenes del software que utiliza su organización. Comercial: ¿Se puede solicitar un SBOM? Código abierto: ¿Tiene un SBOM para los binarios o fuentes que está importando? Tres meses: comprenda qué SBOM necesitan sus clientes Expectativas: ¿qué estándares, profundidad de dependencia, información sobre licencias? Seis meses: prototipo e implementación Implemente SBOM usando una herramienta OSS y/o inicie una conversación con el proveedor. Participe en debates continuos para identificar las mejores prácticas para el ecosistema y contribuya a los proyectos de código abierto desarrollados para respaldar los SBOM.

Pero también hay pasos que puede tomar como individuo:

La próxima semana: juegue con una herramienta SBOM de código abierto y aplíquela a un repositorio. Tres meses: Tener una estrategia SBOM que identifique explícitamente las necesidades de herramientas. Seis meses: Comience la implementación de SBOM utilizando una herramienta OSS o inicie una conversación con el proveedor. Intente consumir el SBOM de otra persona. Asegúrese de compartir cualquier herramienta comercial y de código abierto que le resulte útil y trabaje con las herramientas para reforzarlas, probarlas e informar errores y ampliarlas.

¿Cómo se puede dar forma al futuro de los SBOM?

Primero, quiero destacar algunas oportunidades futuras que han compartido para ayudar a dar forma al futuro de los SBOM. CISA llevará a cabo discusiones de flujo de trabajo público sobre herramientas e implementación en julio de 2022. Son iguales, pero en diferentes horarios para adaptarse a más zonas horarias: 13 de julio de 2022 – 3 p. m. a 4:30 p. m. ET 21 de julio de 2022 – 9:30 a. m. a 11 a. m. ET Si desea asistir, envíe un correo electrónico a SBOM@cisa.dhs .gov. Además, los «Plugfests» se anunciarán en breve y sugirieron que las organizaciones que ya usan SBOM publiquen estudios de casos y flujos de trabajo de herramientas de referencia para ayudar a otros.

Conclusión

Los SBOM llegaron para quedarse. Si aún no lo ha hecho, súbase al tren ahora. Se está mudando fuera de la estación, pero aún tienes la oportunidad de ayudar a definir hacia dónde se dirige y qué tan bien va el viaje. Las diapositivas de Allan y Kate están disponibles aquí. Si se ha registrado para asistir a la conferencia RSA, ahora puede ver la presentación completa bajo demanda aquí.

El paquete de software Data ExchangeⓇ (SPDXⓇ)

Linux Foundation aloja SPDX, un estándar abierto para comunicar información de BOM para software, incluidos componentes, licencias, derechos de autor y referencias de seguridad. SPDX reduce el trabajo redundante al proporcionar un formato común para que las empresas y las comunidades compartan datos críticos, agilizando y mejorando el cumplimiento. La especificación SPDX es un estándar abierto internacional (ISO/IEC 5962:2021). Obtenga más información en spdx.dev.