El desafío clave de seguridad en 2023: la vulnerabilidad del software de código abierto

Hace casi un año, los expertos descubrieron la infame vulnerabilidad del mensaje de error de Log4Shell en la biblioteca Java de código abierto Apache Log4j 2. La debilidad fue solo un ejemplo reciente de una puerta trasera en el software de código abierto para que los atacantes introduzcan código malicioso en los sistemas de desarrolladores y usuarios finales. Desde entonces, ha habido decenas de millones de intentos de comprometer la falla de Log4jShell.

Las dependencias del software de código abierto tienen dependencias

Como un jardinero tratando de agarrar solo una planta de hiedra, un desarrollador de aplicaciones que importa código del ecosistema del software de código abierto a menudo obtiene más de lo que esperaba porque esos paquetes extramuros de repositorios como GitHub a menudo traen consigo dependencias transitivas. Estas son las relaciones secundarias y terciarias que un paquete de software de código abierto tiene con otros códigos de código abierto, formando un sistema "oculto" similar a una raíz de software de procedencia desconocida, invisible para los desarrolladores, intrínsecamente no confiable y potencialmente peligroso.

Un nuevo estudio titulado "El estado de la gestión de dependencias" realizado por Station 9 de Endor Lab reveló que el 95% de todas las vulnerabilidades se encuentran en estos paquetes de código de código abierto que no son seleccionados por los desarrolladores, sino que se incluyen indirectamente en los proyectos.

"Según algunas medidas, por cada dependencia que un desarrollador incorpora a un proyecto de software, hay, en promedio, 77 a 78 dependencias transitivas", dijo Varun Badhwar, cofundador y CEO de Endor Labs. "Además, el 95% de las vulnerabilidades encontradas se encuentran en esas dependencias transitivas, en las cosas que vinieron con las cosas que trajiste. Necesitamos rastrear todo esto en nuestro entorno y comprender en qué aplicaciones se están utilizando estos paquetes".

Henrik Plate, investigador de seguridad en Endor Labs, señaló que escribir software es como armar un BMW.

Protección antivirus en línea: McAfee Clinic lleva la seguridad de tu PC al siguiente nivel

"Estás tomando componentes diversos de otro lugar y los estás ensamblando", dijo Plate.

Badhwar dijo que entre el 80% y el 90% del código en una aplicación moderna típica es "código que no escribimos, es código que tomamos prestado y realmente no sabemos de quién lo estamos tomando. Los atacantes han descubierto esto; el software de código abierto será fundamental para la seguridad de la cadena de suministro de software, por lo que debemos educar mejor al mercado sobre los problemas".

Señaló que el marco de trabajo del Boletín de materiales de software, aunque está diseñado para proporcionar información precisa sobre las dependencias, rara vez lo hace. Especialmente no lo hace para las dependencias transitivas, dada su precisión más o menos en un nivel de dependencia.

Reconociendo la urgencia del problema de seguridad FOSS, el Congreso presentó la Ley de Seguridad del Software de Código Abierto en septiembre de 2022. El proyecto de ley instó a CISA a "publicar públicamente un marco de trabajo que incorpore los marcos y las mejores prácticas del gobierno, la industria y la comunidad de software de código abierto para evaluar el riesgo de los componentes de software de código abierto". No se ha progresado en el proyecto de ley desde su presentación.

¿Qué software de código abierto es crítico?

Los investigadores de Log4j intentaron comprender si existe un consenso sobre los paquetes FOSS más críticos para el software empresarial. Estos son los paquetes que son más utilizados por la mayoría de los desarrolladores y usuarios finales, tienen la funcionalidad más amplia y la mayor exposición potencial a través de las dependencias.

Para hacer esto, exploraron puntuaciones de criticidad de las dos iniciativas comunitarias más populares para identificar proyectos críticos: el "Censo II de bibliotecas de software de código abierto gratuito y de código abierto" soportado por la Fundación Linux y el proyecto Score de Criticidad de Open Source Security Foundation.

Cómo proteger tu computadora de los virus: métodos y consejos

"Queríamos saber si esos enfoques convergen; por lo tanto, si están de acuerdo en lo que es crítico y lo que no lo es", dijo Plate.

No hubo mucho solapamiento en los conjuntos de Census II y OpenSSF Criticality Scores. El estudio señaló que varios paquetes de Census II provenían del mismo proyecto y que 264 paquetes basados en Java en el grupo de Census II provienen solo de 169 proyectos distintos (Figura A).

Figura A

Esto no fue sorprendente para el profesor Justin Cappos de la Escuela de Ingeniería de la NYU Tandon, un experto en seguridad que ha estado trabajando en el espacio de la seguridad de la cadena de suministro de software durante más de una década.

"En realidad, hicimos nuestro propio análisis de qué proyectos de código abierto son críticos y decidimos no publicar los datos porque no pudimos encontrar una métrica lo suficientemente sólida para medir la criticidad", dijo Cappos. "Es un problema difícil".

¡Defiéndete! Protege tu seguridad en línea contra amenazas críticas

El equipo de Endor también descubrió que:

• La mitad de los paquetes de código abierto más utilizados no se actualizaron este año y el 30% tuvo su última versión antes de 2018.
• Hay un 32% de probabilidad de que la última versión de un paquete de software de código abierto tenga vulnerabilidades.
• Cuando se actualiza a la última versión de un paquete, todavía hay un 32% de probabilidad de que tenga vulnerabilidades conocidas.
• El 75% de los paquetes de Census II tienen una puntuación de criticidad inferior a 0,64, en una escala de cero a uno, siendo cero el menos crítico.
• Usar solo métricas de seguridad al tomar decisiones de priorización reduce la probabilidad de una vulnerabilidad en un 20%.

Código abierto: caveat emptor

Badhwar señaló que en última instancia, será responsabilidad de las organizaciones asumir la responsabilidad del proceso de evaluación de FOSS, ya que es su responsabilidad eliminar el software defectuoso una vez que se haya infiltrado en su infraestructura.

"Tomó aproximadamente 33,000 horas para que el departamento de seguridad nacional de EE. UU. descubriera dónde había ido Log4j y luego remediarlo", dijo. "Cada organización y proveedor de software debe rastrear cada componente y dependencia en su entorno, y eso comienza con el seguimiento para generar un inventario a nivel de software de lo que los desarrolladores están obteniendo de Internet".

Plate dijo que la criticidad varía y que esa determinación no se puede externalizar.

"Cada usuario tiene sus propios requisitos de seguridad", dijo. "En última instancia, las organizaciones de desarrollo son responsables de los servicios y productos de software comercial que venden, por lo que estas son otras razones por las que esto no puede ser externalizado a la comunidad de código abierto".

Protege tus contraseñas con PAM: Tu aliado para la seguridad

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a El desafío clave de seguridad en 2023: la vulnerabilidad del software de código abierto , tenemos lo ultimo en tecnología 2023.