¿Qué son los SBOM y qué significan para el software de código abierto? – CloudSavvy IT

Tecnología junio 2, 2021

etiqueta de ingredientes

¿Qué hay dentro del software comercial y de código abierto que utiliza? ¿Cuánto escribió el proveedor y cuánto es código de terceros? ¿Se puede confiar en todo ese código?

Las amenazas son reales

La reciente avalancha de ciberataques de alto perfil demuestra ampliamente los efectos en cadena de los incidentes cibernéticos agresivos. El hack de SolarWinds expuso las redes de sus clientes a la amenaza de ser comprometidas por los ciberdelincuentes. El ataque de Codecov expuso los entornos de implementación continua / integración continua de sus usuarios a los actores de amenazas.

En ambos casos, el ataque a las organizaciones cayó en cascada hacia otros en ese ecosistema: los clientes. Los ataques que paralizan la infraestructura crítica tienen un impacto mucho más amplio. No son solo los clientes de la organización o el servicio afectados los que se ven afectados: las ondas se extienden hacia industrias no relacionadas y la sociedad en general.

El ataque de ransomware de mayo de 2021 contra Colonial Pipeline Company provocó el cierre de un oleoducto de 5.500 millas. Entre otros combustibles refinados, el gasoducto entrega el 45% del suministro de gasolina (2,5 millones de barriles por día de gasolina) a la costa este. La entrega de gasolina simplemente se detuvo. Los precios en los surtidores se dispararon y comenzaron las compras de pánico. Miles de estaciones de servicio tuvieron que cerrar debido a la falta de suministro.

El ataque de Colonial Pipeline Company fue motivado económicamente. Fue un ataque de ransomware, una forma común de extorsión digital. Colonial Pipeline pagó a los ciberdelincuentes un rescate de 75 Bitcoins, aproximadamente $ 4,4 millones, dependiendo de los tipos de cambio, para que les devolvieran sus sistemas.

Pero si esto hubiera sido un acto de ciberterrorismo o guerra cibernética, no habría habido ninguna opción para comprar el programa de descifrado necesario para que los sistemas dañados vuelvan a estar online. Un estado-nación con capacidades ciberofensivas puede hacer que otro país no pueda funcionar internamente a través de una campaña de ciberataques estratégicos.

RELACIONADOS: ¿Necesitas pagar el rescate? Negociar primero

Respondiendo a las amenazas

El 21 de marzo de 2021, el presidente Biden firmó una orden ejecutiva el mejorar la ciberseguridad de la nación. Establece un conjunto de estándares y requisitos que todos los sistemas de información federales deben cumplir o superar.

La sección 4 de la orden ejecutiva trata sobre las formas de mejorar la seguridad de la cadena de suministro de software. Esto coloca deberes sujetos a fechas en los departamentos gubernamentales para proporcionar orientación, estándares y procedimientos para muchos aspectos del desarrollo y adquisición de software. Los proveedores de software deben cumplir con los estándares y seguir los procedimientos para ser proveedores de software elegibles para el gobierno.

La transparencia se cita como requisito. Los proveedores de software deben revelar los componentes y bibliotecas de terceros que se utilizaron en el desarrollo de sus productos. Ese requisito desciende en cascada a lo largo de la cadena de suministro, por lo que los proveedores de esas bibliotecas y componentes deben, a su vez, enumerar cualquier componente de software de origen externo que hayan utilizado en sus productos.

El software de código abierto se menciona específicamente. La orden ejecutiva habla de “garantizar y dar fe, en la medida de lo posible, de la integridad y procedencia del software de código abierto utilizado en cualquier parte de un producto”.

Esto no es sorprendente. Un informe de 2021 sobre seguridad de código abierto encontró que el número promedio de componentes de código abierto en proyectos comerciales no triviales es un asombroso 528. Eso es un aumento del 259% desde hace cinco años cuando el promedio era de 84 componentes de código abierto por proyecto.

RELACIONADOS: Cómo utilizar de forma segura el código fuente abierto en su proyecto

Código abierto como consumible

Claramente, los proyectos de código abierto deben responder a los estándares y procedimientos que se promulgarán como resultado de la orden ejecutiva. A primera vista, la parte de la transparencia debería ser fácil. Los proyectos de código abierto cuelgan su código fuente para cualquier tipo de escrutinio. Pero, por supuesto, los proyectos de código abierto utilizan otros componentes de código abierto, que utilizan otros componentes de código abierto, y así sucesivamente, anidados como muñecos rusos.

Además, las aplicaciones de software tienen dependencias. Dependen de otros paquetes de software para operar. Al elegir incluir un único componente de código abierto en su propio proyecto de desarrollo, es posible que, sin saberlo, incluya muchos otros productos de código abierto como dependencias.

Por lo tanto, tener su código fuente disponible para su revisión no es suficiente. Debe proporcionar una lista de los ingredientes del software en su producto, al igual que la lista de productos alimenticios e ingredientes químicos en un envoltorio de barra de chocolate. En el mundo del software, eso se llama lista de materiales de software o SBOM.

La lista de materiales del software

La seguridad comienza con el conocimiento. Necesita saber lo que tiene para asegurarse de que lo ha asegurado. Es por eso que los registros de activos de TI y los registros de procesamiento de datos son tan importantes. Un SBOM (pronunciado ess-bomb) es un documento específico de la aplicación que enumera todos los elementos de software que componen un producto de software.

Ese es un conocimiento valioso. Tenerlo permite a los usuarios de ese software tomar decisiones de seguridad. Si conoce los componentes presentes en el software, el riesgo asociado con cada uno de ellos y la gravedad de cada riesgo, puede tomar decisiones consideradas e informadas.

Puede leer la lista de ingredientes en el envoltorio de una barra de chocolate y descubrir que contiene algo a lo que es alérgico. Con un SBOM, puede revisar las versiones de compilación, publicar los números de los ingredientes del software y decidir si continuar o no. Por ejemplo, puede negarse rotundamente a utilizar un producto que incorpore (digamos) telnet, o uno que utilice una versión de SSH que tenga una vulnerabilidad conocida.

Elaborar un SBOM detallado no es una tarea de cinco minutos. Pero debe ser precisa y suficientemente detallada, o no cumplirá su propósito. Como línea de base mínima, para cada componente de software en un proyecto de software, un SBOM debe contener:

  • Nombre del proveedor: El proveedor o las personas que escribieron el software.
  • Nombre del componente: El nombre del componente.
  • Identificador único: Un identificador único universal (UUID).
  • Cadena de versión: Los detalles de la versión y la compilación del componente.
  • Hash de componentes: Un hash criptográfico del componente. Esto permite que un destinatario verifique, si tiene sospechas, si se ha modificado un binario que se le ha proporcionado.
  • Relación: La relación entre los componentes de software describe las dependencias entre los componentes y qué componentes se han compilado y vinculado a otros componentes.
  • Licencia: El tipo de licencia con la que se publica el componente de software.
  • Nombre del autor: El autor del SBOM. Este no es necesariamente el proveedor de software.

Si va a haber una amplia adopción de SBOM, debe haber un estándar que defina los formatos de datos, el contenido de los datos y los procesos y normas aceptados. Es probable que esto aparezca como parte de la guía que la orden ejecutiva ha solicitado que se cree.

Hay varios estándares SBOM en competencia. Los tres pioneros en este espacio son Intercambio de datos de paquetes de software (SPDX), el estándar ISO 19770-5: Identificación de software 2013 (SWID) y CycloneDX. Será interesante ver si el gobierno federal adopta uno de estos como su estándar preferido.

La automatización puede ayudar

Varias clases de herramientas pueden ayudar con la producción y el uso de SBOM. Hay paquetes de software disponibles que pueden escanear proyectos, determinar dependencias y generar SBOM, o SBOM casi completos en los que puede incluir algunos detalles finales.

Los SBOM probablemente estarán disponibles como descargas o como parte del software empaquetado, al igual que un archivo “Léame”. Una vez que esté en posesión del SBOM de otra persona, debe revisarlo.

Eso llevará tiempo. Será necesario verificar cada componente para asegurarse de que sea permisible de acuerdo con los criterios que haya establecido su organización y de que la licencia de cada componente no le cause ningún conflicto.

Hay software disponible que puede realizar estas comprobaciones por usted. Los paquetes más completos enumeran las vulnerabilidades conocidas para cada componente y la gravedad de esas vulnerabilidades.

La seguridad comienza con el conocimiento

La procedencia de los paquetes de software y todos sus componentes se convertirá en una herramienta vital para que los consumidores de software evalúen y tomen decisiones de compra. También será un diferenciador para los proveedores y productores de software, ya sea que creen software para otros desarrolladores o para que lo utilicen los usuarios finales.