El reciente descubrimiento de una puerta trasera en la utilidad de compresión de datos XZ Utils, que se incluye en casi todas las principales distribuciones de Linux, significa que las organizaciones que utilizan componentes de código abierto pueden terminar teniendo que proteger su software. Este es un fuerte recordatorio de nuestra responsabilidad.
XZ Utils, como miles de otros proyectos de código abierto, está dirigido por voluntarios, en cuyo caso lo gestiona un único responsable. Estos proyectos suelen tener pocos o ningún recurso para abordar los problemas de seguridad y las organizaciones utilizan el software bajo su propia responsabilidad. Eso significa que los equipos de seguridad y desarrollo deben tomar medidas para gestionar los riesgos del código abierto tal como lo harían con el código desarrollado internamente, dicen los expertos en seguridad.
“Si bien es poco probable que las organizaciones puedan prevenir eficazmente [all] “Para reducir su exposición a los riesgos de la cadena de suministro, las organizaciones deben centrarse en estrategias que reduzcan la probabilidad de un ataque exitoso a la cadena de suministro”, dijo Jamie Scott, gerente de producto fundador de Endor Masu.
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 del software y somos responsables del software que reutilizamos”.
Buenas intenciones, falta de recursos.
Las preocupaciones sobre la seguridad del software de código abierto no son nada nuevo. Sin embargo, descubrimientos como la vulnerabilidad Log4Shell y la puerta trasera XZ Utils a menudo hacen que las organizaciones se den cuenta de cuán vulnerables son a los componentes de su código. Y en muchos casos, el código proviene de proyectos de código abierto bien intencionados pero con una desesperada falta de recursos y un mantenimiento mínimo.
Por ejemplo, XZ Utils es esencialmente un proyecto de una sola persona. Poco a poco, otra persona se ganó la confianza suficiente de la dirección del proyecto para introducir con éxito una puerta trasera en la empresa de servicios públicos durante un período de casi tres años. Si los desarrolladores de Microsoft no hubieran descubierto la puerta trasera por casualidad mientras investigaban comportamientos extraños relacionados con las instalaciones de Debian a finales de marzo, la puerta trasera se habría infiltrado en millones de dispositivos en todo el mundo, incluidos dispositivos de grandes empresas y agencias gubernamentales. Al final, la puerta trasera tuvo un impacto mínimo ya que 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.
La próxima violación del código fuente abierto podría ser mucho peor. “Lo más aterrador para las empresas es que sus aplicaciones se basan en proyectos de software de código abierto como XZ Utils”, dice Donald Fischer, cofundador y director ejecutivo de Tidelift. “XZ Utils es uno de las decenas de miles de paquetes que se utilizan todos los días en una empresa típica”, afirma.
Señala que la mayoría de estas organizaciones carecen de suficiente visibilidad de la seguridad y resiliencia de esta parte de la cadena de suministro de software para evaluar el riesgo.
Un estudio reciente de la Escuela de Negocios de Harvard estima que el valor de la demanda del software de código abierto asciende a la asombrosa cifra de 8,8 billones de dólares. Los mantenedores están en el corazón de este ecosistema y muchos trabajan solos, dijo Fisher. En una encuesta realizada por Tiderift el año pasado, el 44% de los mantenedores de proyectos de código abierto se describieron a sí mismos como los únicos mantenedores del proyecto. El 60% se identificó como aficionado no remunerado y el mismo porcentaje dijo que había renunciado o considerado dejar su rol como mantenedor de proyectos. Muchos encargados de mantenimiento describen su trabajo como estresante, solitario y financieramente poco gratificante, dijo Fisher.
“El hackeo de XZ utils resalta los riesgos de invertir poco en la salud y la resiliencia de las cadenas de suministro de software de código abierto. [that] “Las organizaciones deben darse cuenta de que la mayoría de los paquetes de código abierto de los que dependen son mantenidos por voluntarios que se autodenominan aficionados no remunerados. “No, pero se espera que trabajemos y entreguemos como ellos”, dice Fisher.
Peligro: dependencias transitivas
Según una investigación realizada por Endor en 2022, el 95% de las vulnerabilidades de código abierto se encuentran en las llamadas dependencias transitivas, es decir, en paquetes o bibliotecas secundarios de código abierto de los que el paquete principal de código abierto puede depender. Suelen ser paquetes que los paquetes de código abierto utilizan automáticamente en proyectos de desarrollo, en lugar de ser seleccionados directamente por los desarrolladores.
“Por ejemplo, confiar en un paquete Maven da como resultado que se confíe implícitamente en un promedio de 14 dependencias”, dice Scott. “Este número es aún mayor en ciertos ecosistemas de software, como NPM, donde cada paquete confiable importa un promedio de otros 77 componentes de software”.
La primera forma de reducir el riesgo del código abierto, afirma, es prestar atención a estas dependencias y tener cuidado con los proyectos que se eligen.
Dimitri Stiliadis, CTO y cofundador de Endor, añade que las organizaciones necesitan examinar las dependencias, especialmente los paquetes pequeños y únicos gestionados por equipos de una o dos personas. Las organizaciones necesitan saber si las dependencias en su entorno cuentan con controles de seguridad adecuados, si un individuo ha confirmado todo el código, si hay archivos binarios en el repositorio que nadie conoce o si alguien ha confirmado. Incluso necesita determinar si estás manteniendo activamente el proyecto, dice Stiliadis.
“Concéntrese en aumentar la eficacia de su respuesta. Los controles fundamentales, como mantener un inventario de software maduro, son los controles más eficaces que puede implementar para identificar, evaluar y responder a los riesgos de software tan pronto como se identifiquen. programas más valiosos que existen”, aconseja Scott.
Las herramientas de análisis de configuración de software, los escáneres de vulnerabilidades, los sistemas EDR/XDR y los SBOM pueden ayudar a las organizaciones a identificar rápidamente componentes de código abierto vulnerables y comprometidos.
Reconocer la amenaza
“Para reducir el riesgo, es importante que los ejecutivos y las necesidades comiencen a compartirse a nivel de la junta directiva”, dice Fisher de Tidedrift.
Las nuevas regulaciones y directrices de la industria de servicios financieros, la FDA y el NIST darán forma a la forma en que 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 pasiva a una proactiva en la gestión de riesgos relacionados con el código abierto”, afirma.
Fisher recomienda que las organizaciones hagan que sus equipos de seguridad e ingeniería identifiquen cómo ingresan al entorno los nuevos componentes de código abierto. También debe definir roles para monitorear estos componentes y eliminar proactivamente los componentes que no cumplan con la tolerancia al riesgo de su empresa. “En los últimos años, el gobierno de Estados Unidos ha demostrado que responder a los problemas de última hora ya no es eficaz para abordar la magnitud de los riesgos para las empresas, y que esos días están llegando a su fin”, afirma.
Fuente: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security
