El reciente descubrimiento de una puerta trasera en la utilidad de compresión de datos XZ Utils, presente en casi todas las principales distribuciones de Linux, es un claro recordatorio de que las organizaciones que consumen componentes de código abierto son, en última instancia, responsables de proteger el software.

XZ Utils, como miles de otros proyectos de código abierto, está gestionado por voluntarios y, en su caso, tiene un único mantenedor que lo gestiona. Estos proyectos suelen tener pocos o ningún recurso para gestionar los problemas de seguridad, lo que significa que las organizaciones utilizan el software bajo su propia responsabilidad. Eso significa que los equipos de seguridad y desarrollo deben implementar medidas para gestionar el riesgo del código abierto de la misma manera que lo hacen con el código desarrollado internamente, dicen los expertos en seguridad.

"Si bien es poco probable que una organización pueda prevenir eficazmente [toda] la exposición a los riesgos de la cadena de suministro, las organizaciones pueden centrarse absolutamente en una estrategia para reducir la probabilidad de que un ataque a la cadena de suministro tenga éxito", dice Jamie Scott, gerente de producto fundador de Endor Labs.

El código abierto no es lo mismo que la subcontratación: “Los mantenedores de software de código abierto son voluntarios. A nivel industrial, debemos tratarlos como tales. Somos dueños de nuestro software; somos responsables del software que reutilizamos”.

Bien intencionados, con pocos recursos

Preocupaciones por la seguridad del software de código abierto no son en modo alguno nuevos. Pero a menudo hacen falta descubrimientos como el Vulnerabilidad de Log4Shell y del puerta trasera en XZ Utils para dejar claro cuán vulnerables son las organizaciones a los componentes de su código. Y, a menudo, el código proviene de proyectos de código abierto bien intencionados pero irremediablemente carentes de recursos y que reciben un mantenimiento mínimo.

XZ Utils, por ejemplo, es esencialmente un proyecto de una sola persona. Otro individuo logró introducir la puerta trasera en la utilidad durante un período de casi tres años, ganando gradualmente suficiente confianza por parte del responsable del proyecto. Si un desarrollador de Microsoft no se hubiera topado con ella a finales de marzo mientras investigaba un comportamiento extraño asociado con una instalación de Debian, la puerta trasera bien podría haber terminado en millones de dispositivos en todo el mundo, incluidos aquellos que pertenecen a grandes corporaciones y agencias gubernamentales. Al final resultó que, la puerta trasera tuvo un impacto mínimo porque afectó a las versiones de XZ Utils que solo estaban presentes en las versiones beta e inestable de Debian, Fedora, Kali, SUSE abierto y Arch Linux.

El próximo compromiso del código fuente abierto podría ser mucho peor. "La parte más aterradora para las organizaciones empresariales es que sus aplicaciones se crean sobre proyectos de software de código abierto como XZ Utils", dice Donald Fischer, cofundador y director ejecutivo de Tidelift. "XZ Utils es un paquete de decenas de miles que las organizaciones empresariales típicas utilizan todos los días", afirma.

La mayoría de estas organizaciones carecen de suficiente visibilidad sobre la seguridad y la resiliencia de esta parte de su cadena de suministro de software para poder evaluar el riesgo, señala.

Un Harvard Business School Un estudio estimó que el valor del software de código abierto desde el punto de vista de la demanda asciende a la asombrosa cifra de 8.8 billones de dólares. Los mantenedores son el núcleo de este ecosistema y muchos de ellos vuelan solos, dice Fischer. Una encuesta realizada por Tidelift el año pasado encontró que el 44% de los mantenedores de proyectos de código abierto se describen a sí mismos como los únicos mantenedores de sus proyectos. El sesenta por ciento se identificó como aficionado no remunerado y el mismo porcentaje dijo que había renunciado o había considerado dejar sus funciones como mantenedores de proyectos. Muchos encargados de mantenimiento describieron sus esfuerzos como un trabajo estresante, solitario y económicamente poco gratificante, dice Fischer.

"El hackeo de XZ utils pone de relieve los riesgos de invertir poco en la salud y la resiliencia de la cadena de suministro de software de código abierto [de la que] dependen las organizaciones empresariales", dice Fischer. “Las organizaciones empresariales deben darse cuenta de que la mayoría de los paquetes de código abierto más confiables son mantenidos por voluntarios que se describen a sí mismos como aficionados no remunerados. Estos mantenedores no son proveedores empresariales, pero se espera que trabajen y cumplan como ellos”.

Peligro: dependencias transitivas

A estudio que realizó Endor en 2022 descubrió que el 95% de las vulnerabilidades de código abierto están presentes en las llamadas dependencias transitivas, o bibliotecas o paquetes secundarios de código abierto de los que podría depender un paquete primario de código abierto. A menudo, estos son paquetes que los desarrolladores no seleccionan directamente ellos mismos, sino que son empleados automáticamente por un paquete de código abierto en su proyecto de desarrollo.

"Por ejemplo, cuando confías en un paquete Maven, como resultado, en promedio, hay 14 dependencias adicionales en las que confías implícitamente", dice Scott. "Este número es aún mayor en ciertos ecosistemas de software como NPM, donde en promedio se importan otros 77 componentes de software por cada uno en el que confía".

Una forma de empezar a mitigar los riesgos del código abierto es prestar atención a estas dependencias y ser selectivo sobre los proyectos que eliges, afirma.

Las organizaciones deberían examinar las dependencias, especialmente los paquetes más pequeños y únicos, atendidos por equipos de una o dos personas, añade Dimitri Stiliadis, CTO y cofundador de Endor. Deben determinar si las dependencias en su entorno tienen controles de seguridad adecuados o si un solo individuo confirma todo el código; si tienen archivos binarios en sus repositorios que nadie conoce; o incluso si alguien mantiene activamente el proyecto, dice Stiliadis.

"Concentre sus esfuerzos en mejorar la eficacia de su respuesta: los controles fundamentales, como el mantenimiento de un inventario de software maduro, siguen siendo uno de los programas de mayor valor que puede implementar para identificar, evaluar y responder rápidamente a los riesgos de software una vez identificados", Scott aconseja.

Las herramientas de análisis de composición de software, los escáneres de vulnerabilidades, los sistemas EDR/XDR y los SBOM también pueden ayudar a las organizaciones a identificar rápidamente componentes de código abierto vulnerables y comprometidos.

Reconociendo la amenaza

"Mitigar la exposición comienza con la comprensión y el reconocimiento compartidos en la alta dirección e incluso a nivel de la junta directiva de que aproximadamente el 70% de los ingredientes del producto de software promedio son software de código abierto históricamente creado por contribuyentes en su mayoría no remunerados", dice Fischer de Tidelift.  

Las nuevas regulaciones y directrices en la industria de servicios financieros, la FDA y el NIST darán forma a cómo se desarrollará el software en los próximos años y las organizaciones deben prepararse para ellas ahora. "Los ganadores aquí se adaptarán rápidamente de una estrategia reactiva a una estrategia proactiva para gestionar el riesgo relacionado con el código abierto", afirma.

Fischer recomienda que las organizaciones hagan que sus equipos de seguridad e ingeniería identifiquen cómo llegan los nuevos componentes de código abierto a su entorno. También deberían definir roles para monitorear estos componentes y eliminar proactivamente aquellos que no se ajusten al apetito de riesgo de la empresa. “Reaccionar a los problemas en las últimas etapas se ha convertido en una forma ineficaz de abordar la magnitud del riesgo para el negocio en los últimos años, y el El gobierno de Estados Unidos está dando señales esa era está llegando a su fin”, afirma.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security