3 consejos para crear un SBOM Matt Psencik, Tanium

Acrónimo de Software Bill of Materials, SBOM describe los componentes de software utilizados en el software o un sistema. Los SBOM tienen como objetivo reducir el riesgo y mejorar la transparencia y la seguridad en torno a las aplicaciones producidas por la empresa. Aquí hay 3 consejos para crearlos.

Los desarrolladores y los profesionales de la seguridad aún tienen en mente el daño causado por la vulnerabilidad Log4j identificada en diciembre de 2021. En las organizaciones, los numerosos ataques que siguieron, sin mencionar las noches de insomnio que pasaron tratando de corregir las vulnerabilidades, han hecho tomar conciencia del riesgo de apertura. -componentes de origen y cómo las cadenas de suministro de software a menudo estaban en alto riesgo.

Esta sensación de vulnerabilidad ha llevado a muchas organizaciones a tomar medidas concretas. Como resultado, los equipos de desarrollo comenzaron a trabajar más de cerca con los equipos de seguridad cibernética para fortalecer sus cadenas de suministro utilizando listas de materiales de software (SBOM). De hecho, el año pasado, las organizaciones incrementaron en un 30% la creación y mantenimiento de SBOM. El objetivo es ayudar a las organizaciones a protegerse contra los riesgos introducidos por el uso de software libre y la integración de códigos de fuente abierta al proporcionar una lista de los componentes, las bibliotecas, que constituyen el software final. Como una lista de ingredientes para un pastel, los SBOM brindan visibilidad de todos los «ingredientes», de código abierto y comerciales, que componen el software.

Pero todavía queda un largo camino por recorrer para muchas organizaciones, ya que simplemente no tienen la madurez y/o los recursos para implementar el uso a gran escala de SBOM. Dicho esto, es un paso esencial para garantizar la seguridad de su organización. Con eso en mente, aquí hay tres consejos clave para cualquier organización que busque comenzar o mejorar su implementación de SBOM.

Tener capacidades de remediación en tiempo real

La economía actual está impulsada por el software libre, pero el proyecto de desarrollo de aplicaciones promedio contiene casi cincuenta vulnerabilidades repartidas en ochenta dependencias directas (según un informe de Snyk). Para empeorar las cosas, las dependencias indirectas son mucho más difíciles de rastrear: cada biblioteca de terceros utilizada en un proyecto trae capas adicionales de código que los equipos de desarrollo ahora deben rastrear. Puede llevar semanas o incluso meses solucionar manualmente estos problemas. Para resolverlo, una solución SBOM bien diseñada no solo debe identificar las vulnerabilidades, sino también corregirlas en tiempo real. Los SBOM están ahí para ayudar a los desarrolladores a comprender los componentes básicos de las bibliotecas compartidas que componen las aplicaciones y los sistemas operativos de una organización. Pero para ser verdaderamente eficaz, la solución debe ir más allá remediando lo identificado. Con millones de bibliotecas de código abierto en uso, las capacidades de remediación son una necesidad.

Confíe en los datos de punto final

Supongamos que los equipos de seguridad y TI conocen una vulnerabilidad de código abierto en la cadena de suministro de software. El primer paso es encontrar la ubicación de esta falla de día cero en todos sus puntos finales. Un estudio reciente mostró que el 68% de las organizaciones en todo el mundo ya han sufrido uno o más ataques en sus puntos finales que han comprometido los datos o su infraestructura de TI. Los puntos finales son los activos que tienen un impacto inmediato en los usuarios finales, por lo que cuando se crea un SBOM, la organización debe poder escanear archivos específicos en esos puntos finales.

Para las organizaciones, esto significa centrarse en encontrar daños en todos los activos individuales y examinar individualmente el contenido de los archivos presentes en el entorno informático haciendo las preguntas correctas. ¿Cuántos endpoints tienen esta vulnerabilidad específica? ¿Conoces todos los dispositivos de tu red? ¿Cuál es el estado de limpieza y descubrimiento?

Las dos vulnerabilidades descubiertas en la biblioteca OpenSSL en noviembre de 2022 ilustran perfectamente el impacto considerable que una sola vulnerabilidad puede tener en los millones de puntos finales que utilizan la plataforma. Al aprovechar los datos de puntos finales para analizar la composición del software, las organizaciones podrán identificar esta vulnerabilidad y otras similares en la cadena de suministro de software.

Garantice el más alto nivel de visibilidad

La visibilidad granular en tiempo real es un requisito clave para una SBOM efectiva, porque lo que no sabe no se puede proteger. El SBOM debe contener una lista exhaustiva de todos los paquetes y bibliotecas compartidas utilizadas en cada aplicación, junto con su número de versión. De esta forma, si se publica una vulnerabilidad para un paquete específico, es posible actualizar ese paquete, eliminarlo o contactar al proveedor para ver si hay un nuevo parche disponible.

Al contar con una base de conocimientos tan dinámica, es posible estar un paso por delante de quienes buscan explotar una vulnerabilidad de este tipo. Por ejemplo, cuando se descubrió la vulnerabilidad Log4j, muchos investigadores de seguridad intentaron explotar la vulnerabilidad a ciegas en sus propios laboratorios. Rápidamente descubrieron que muchos proveedores ni siquiera habían informado que se habían visto afectados. Con un SBOM, este enfoque ciego no sería necesario porque los investigadores habrían tenido visibilidad sobre exactamente dónde investigar con más detalle.

Sin embargo, las vulnerabilidades de las bibliotecas compartidas y las cadenas de suministro de software se están volviendo más comunes a medida que las empresas continúan confiando en componentes de código abierto para crear código rápidamente. Aunque los SBOM son una parte esencial de una estrategia de seguridad de la cadena de suministro de software, la creación y el mantenimiento de dicha herramienta es principalmente responsabilidad del equipo de desarrollo. Por lo tanto, como desarrollador, es necesario aprender cómo utilizar mejor un SBOM porque brinda una visibilidad que puede significar la diferencia entre un incidente operativo menor y una interrupción completa del negocio con consecuencias a largo plazo.

En los próximos años, los riesgos de la cadena de suministro de software seguirán siendo el centro de atención. Para cualquier persona en esta cadena, es imperativo utilizar herramientas de análisis de composición de software (SCA), especialmente SBOM, para que la organización pueda identificar dónde está la próxima vulnerabilidad de OpenSSL o Log4j antes de que solo se propague.
___________________

por Matt Psencik, director de seguridad de puntos finales chez tanio

Lea también:

Ciberresiliencia y eficiencia, pilares de la transformación de la industria automotriz

Espacios de trabajo digitales y seguridad, el difícil equilibrio…

Los 4 pasos de una buena gestión de operaciones…

Tanium también se interesa por la experiencia del empleado

Tanium amplía la cobertura de su plataforma XEM

¡Felicitaciones, se ha suscrito con éxito a nuestro boletín de noticias!

[