Los SBOM siguen siendo más obligatorios que colaterales

Las listas de materiales de software tienen su momento.

Luego de una orden ejecutiva emitida por la administración de Biden en mayo de 2021, los manifiestos de software, que describen los componentes y las dependencias que se usan tanto directa como indirectamente para desarrollar aplicaciones, ahora son requeridos por el gobierno de los EE. UU. para todos los contratistas federales. Dada la barra baja para la producción A SLista de materiales del software (SBOM) — Una variedad cada vez mayor de herramientas utilizadas durante el desarrollo también puede conducir a esto. — Las listas de componentes de la aplicación son cada vez más numerosas. Por esta razón, casi la mitad de todas las empresas ahora también requieren SBOM para todo el software. Para 2025, se proyecta que ese número alcance el 60 %, en comparación con menos del 5 % en 2022 Datos de la empresa de investigación de mercado Gartner.

Las regulaciones federales han provocado una corrida de SBOM y cambios en la forma en que los desarrolladores documentan su software, dice Stephen Magill, vicepresidente de innovación de productos en Sonatype, una empresa de herramientas de desarrollo de software.

“Los mandatos SBOM del gobierno y los reguladores brindan un incentivo importante para mejorar su proceso de desarrollo y adoptar una herramienta”, dice. “Esa es una de las principales razones por las que estas normas entran en vigor. Esto se debe a que la industria no ha adoptado ampliamente estas herramientas, y el código abierto continúa siendo una gran área de riesgo que simplemente no se gestiona en muchas organizaciones”.

La prisa por mantenerse al día con los mandatos gubernamentales está conduciendo a una rápida evolución dentro de la industria a medida que los estándares intentan acomodar varios factores que intervienen en el desarrollo de software. En junio, por ejemplo, el Open Worldwide Application Security Project (OWASP) anunció Versión 1.5 de su estándar SBOM CycloneDXque ahora contiene información sobre los modelos de aprendizaje automático (ML) utilizados en una aplicación determinada, así como una medida de la calidad del SBOM.

Si bien los SBOM actuales a menudo son poco más que listas de componentes de software, el objetivo final es brindar a las organizaciones una forma de identificar y documentar las vulnerabilidades en su software, dice Thomas Pace, director ejecutivo de la empresa de seguridad IoT extendida NetRise.

«Actualmente, los usuarios finales tienen dificultades para tomar decisiones basadas en datos incompletos, especialmente cuando se trata de… dispositivos que ejecutan firmware, que sigue siendo una caja negra para la gran mayoría de las organizaciones», dice. «Una vez que tienen estos SBOM, finalmente pueden tomar decisiones basadas en datos sobre el riesgo de los diferentes dispositivos, aplicaciones y sistemas que utilizan».

Estándares SPDX, CycloneDX y SWID

EE.UU El gobierno reconoce tres estándares SBOM para cumplir con sus requisitos mínimos: etiquetas de identificación de software (SWID), intercambio de datos del paquete de software (SPDX) y CycloneDX.

En 2009, la Organización Internacional de Normalización (ISO) creó etiquetas SWID para ayudar a las organizaciones a rastrear el software instalado en sus sistemas administrados. Hace más de una década, la Fundación Linux creó SPDX para respaldar el intercambio de información sobre licencias. En 2017, OWASP desarrolló CycloneDX para intercambiar datos sobre SBOM.

Los tres estándares se superponen significativamente, pero SPDX y CycloneDX parecen tener el mayor impulso. También hay matices entre ellos: SPDX aún se enfoca más en la administración de licencias y el grado en que admite la legibilidad de la máquina. En la práctica, sin embargo, tanto los consumidores como los proveedores de SBOM deberían poder trabajar con los formatos, dice Fernando Montenegro, analista principal senior de seguridad cibernética en la firma de analistas Omdia, una empresa hermana de Dark Reading.

“Si es un desarrollador, puede usar SBOM para rastrear más fácilmente las dependencias que incorpora en su propio software a medida que agrega diferentes módulos. Esto le ayudará a tomar mejores decisiones de seguridad”, dice. «Si usted es un equipo de seguridad, los SBOM proporcionados por sus proveedores pueden ayudarlo a comprender qué componentes se ejecutan en su entorno… puede priorizar más fácilmente las acciones de remediación en sus sistemas».

Ir más allá de la conciencia

La visibilidad y la notoriedad son actualmente los principales beneficios de los SBOM. Por ejemplo, los SBOM de CycloneDX contienen información sobre las licencias de software, los servicios de código bajo y los modelos de aprendizaje automático utilizados en el desarrollo, así como anotaciones e información de divulgación de vulnerabilidades. Porque el 95% de las vulnerabilidades no están en el dependencias directas utilizadas para construir software pero en el dependencias indirectas introducidas por los desarrolladores de estos componentesSegún Jamie Scott, gerente de producto de Endor Labs, una empresa de gestión de riesgos de software, la mayoría de las empresas no tienen una buena comprensión de los riesgos del software que adquieren.

«La gente quiere comprender su software y su inventario para poder tomar decisiones informadas de gestión de riesgos, y les está yendo razonablemente bien con SCA». [software composition analysis] por el software que hacen”, dice. «Pero carecen de esa visibilidad del software que están adquiriendo. Por lo tanto, los SBOM se tratan de obtener visibilidad de sus aplicaciones propias y de terceros para que tenga un inventario de software completo».

Aún así, los SBOM se están volviendo cada vez más operativos, dice Zach Capers, analista senior de seguridad de Capterra, una empresa de servicios de mercado de software. Las encuestas de la empresa muestran que casi la mitad (49%) de las empresas requieren SBOM como parte de su proceso actual de adquisición de software.

“Así como los compradores de software pueden usar SBOM para aumentar la visibilidad en su cadena de suministro de software, los desarrolladores de software pueden rastrear mejor los componentes utilizados para construir sus productos”, dice. «Todavía estamos en las primeras etapas, pero eventualmente escuchará sobre una vulnerabilidad recién descubierta y, gracias a los SBOM, podrá determinar de inmediato si está o no al acecho en algún lugar de la pila de software de su empresa».

Los cambios actuales tienen más que ver con ampliar el alcance de lo que se documenta mediante SBOM. En última instancia, sin embargo, una serie de medidas de riesgo, y posibles controles de seguridad, también podrían consagrarse en los SBOM, lo que podría conducir a esto. un reglamento sobre la responsabilidad del software.

Aprendizaje automático, automatización en el punto de mira

Cuando los atacantes comenzaron a explotar las vulnerabilidades de Log4j utilizando la prueba de concepto de Log4Shell, las empresas buscaban desesperadamente una forma de averiguar si el componente de código abierto ampliamente utilizado estaba en sus entornos.

Cuando los profesionales de seguridad «piensan en Log4Shell, el desafío para muchas organizaciones es responder si están usando Log4j y son vulnerables», dice Josh Thorngren, jefe de representación de desarrolladores en ForAllSecure, una empresa de pruebas de seguridad. «Las organizaciones con SBOM pueden responder a esta pregunta más rápido que las que no». [and] Con el tiempo, veremos estas diferencias y escucharemos las reacciones de los profesionales de la seguridad en la naturaleza”.

Además, es probable que los sistemas de software automaticen sus respuestas a las vulnerabilidades conocidas. Según Pace de NetRise, las empresas comprenderán las vulnerabilidades de sus productos, en particular las creadas por dependencias indirectas, y, tras el anuncio de una nueva vulnerabilidad, podrán implementar controles.

«Ahora puede implementar un control de compensación que detecte el tráfico dirigido a ese dispositivo, específicamente cerca de esos… exploits disponibles, que es básicamente de lo que son capaces todos los firewalls y sistemas de detección de intrusos actuales», dice pace. «Sin el SBOM, está completamente ciego a estos riesgos y solo espera que los fabricantes de dispositivos hayan desarrollado un dispositivo completamente seguro, lo que por supuesto es imposible».