Aquí hay una solución para los ataques a la cadena de suministro de código abierto

Comentario: El código abierto nunca ha sido más popular o más atacado, pero hay algo que los proveedores de la nube pueden hacer para que OSS sea más seguro.

Imagen: Kheng Guan Toh / Shutterstock

El escritor colaborador de TechRepublic, Jack Wallen, tiene razón en que “el software de código abierto ha demostrado, una y otra vez, que es apto para empresas durante mucho tiempo”. Sonatype también tiene razón en que los ataques a la cadena de suministro contra los populares repositorios de software de código abierto aumentaron un 650% durante el último año. De hecho, es la popularidad de ese software de código abierto lo que lo convierte en un objetivo principal.

Aunque el presidente Biden ha pedido un mayor enfoque en la seguridad e integridad del software de código abierto, no estamos más cerca de saber cómo lograrlo. Algunos proyectos más grandes como Kubernetes tienen el respaldo corporativo necesario para garantizar una inversión significativa en la protección del software, mientras que otros pueden ser muy utilizados, pero pueden ser el trabajo del amor de un puñado de desarrolladores. Ningún mandato federal regalará mágicamente los recursos necesarios para actualizar constantemente estos proyectos menos económicos.

Y, sin embargo, hay esperanza. Los proveedores de la nube y otros incorporan cada vez más software de código abierto para ofrecer ofertas integrales. Es posible que los clientes puedan recurrir a ellos para garantizar la seguridad del código que operan.

VER: Política de respuesta a incidentes de seguridad (TechRepublic Premium)

Código abierto bajo ataque

El código abierto sigue creciendo en popularidad, por una suma de 2,2 billones de paquetes de código abierto extraídos de repositorios como npmjs y Maven en 2021, según el estudio de Sonatype. A medida que el software se vuelve fundamental para el funcionamiento de la mayoría de las organizaciones, los desarrolladores deben construir con una velocidad cada vez mayor. Con más de 100 millones de repositorios disponibles solo en GitHub, muchos de ellos de alta calidad, los desarrolladores recurren al código abierto para obtener un excelente software rápidamente.

Eso es lo bueno. Pero no del todo.

Sonatype examinó el 10% superior de los proyectos más populares de Java, JavaScript, Python y .NET, y descubrió que el 29% de ellos contienen al menos una vulnerabilidad de seguridad conocida. A medida que continúa el informe, la antigua forma de explotar las vulnerabilidades en los proyectos de código abierto sería buscar agujeros de seguridad sin parchear y de acceso público en el código fuente abierto. Pero ahora, los piratas informáticos “están tomando la iniciativa e inyectando nuevas vulnerabilidades en proyectos de código abierto que alimentan la cadena de suministro global, y luego explotan esas vulnerabilidades”.

Hasta ahora, los repositorios de Node.js (npm) y Python (PyPI) han sido los objetivos principales. ¿Cómo se infiltran los atacantes en las corrientes ascendentes de los proyectos populares? Hay algunas formas, aunque la más destacada se llama dependencia o confusión de espacio de nombres.

Como señalaron los autores del informe: “El nuevo vector de ataque altamente dirigido permite que se introduzca código malicioso o no deseado automáticamente sin depender de técnicas de typosquatting o brandjacking. La técnica implica que un mal actor determina los nombres de los paquetes patentados (fuente interna) utilizados por la aplicación de producción de una empresa. Equipado con esta información, el mal actor publica un paquete malicioso con el mismo nombre exacto y una versión semántica más reciente en un repositorio público, como npmjs, que no regula la identidad del espacio de nombres “.

Estos y otros ataques novedosos están empezando a acumularse (Figura A).

Figura A

Imagen: Sonatype

Existen al menos dos dificultades inherentes a la mejora de la seguridad del código abierto. La primera que he mencionado: no todos los mantenedores de proyectos tienen los recursos o el conocimiento para asegurar su código de manera efectiva. En el extremo receptor, muchas empresas no se apresuran a parchear incluso los problemas de seguridad conocidos. Pero eso no quiere decir que las cosas sean desesperadas. Lejos de ahi.

Se que las piezas encajan

Es demasiado pronto para llamarlo una tendencia, pero el analista de RedMonk, Stephen O’Grady, ha destacado los primeros indicadores de un cambio en la industria de las primitivas de infraestructura aisladas (por ejemplo, computación, almacenamiento, etc.) hacia flujos de trabajo abstractos e integrados. Como dijo, “[V]Los patrocinadores están evolucionando más allá de sus áreas originales de competencia central, extendiendo su base funcional horizontalmente para brindar una experiencia de desarrollador más completa e integrada. Desde el control de versiones hasta la supervisión, las bases de datos y los sistemas de compilación, cada parte del flujo de trabajo de desarrollo de una aplicación debe integrarse mejor y sin problemas “.

Todo esto en un esfuerzo por facilitar la vida de los desarrolladores.

¿Qué ha dificultado su trabajo? En una publicación más reciente, señaló: “Donde la primera, y en ocasiones, la única prioridad de un desarrollador, alguna vez pudo haber sido la escala, hoy es mucho más probable que sea la velocidad”. Como se señaló anteriormente, esa “necesidad de velocidad” está impulsando a los desarrolladores a adoptar el código abierto, al igual que los está impulsando a adoptar la nube. Cualquier cosa y todo lo que elimine la fricción para que puedan crear e implementar software más rápidamente. A menudo, reciben ese código abierto como servicios administrados, lo que elimina la fricción de hardware y software, lo que permite a los desarrolladores moverse a la máxima velocidad con un mínimo de restricciones.

VER: Política de selección y gestión de proveedores (TechRepublic Premium)

Pero no se trata simplemente de que un proveedor de la nube haga que, digamos, Apache Kafka esté disponible como un servicio. No, lo que está sucediendo, dijo O’Grady, es el empaquetado de (en este ejemplo) Kafka como parte de un servicio en la nube más grande: “En lugar de proporcionar una capa sobre el hardware base, los sistemas operativos u otras primitivas subyacentes similares, abstraen un toda la infraestructura se apila y proporciona una función o servicio gestionado especializado de mayor nivel “.

Esto nos devuelve a esos ataques a la cadena de suministro.

Si los proveedores envían cada vez más “funciones gestionadas especializadas de nivel superior[s] o servicio[s], “presumiblemente también estarán en peligro por la procedencia y la seguridad de los componentes de ese servicio. Esto debería llevar a más proveedores de nube a invertir en el desarrollo, el mantenimiento y la seguridad continuos de estos componentes, por no mencionar la situación contractual detrás de esos componentes para los clientes. Un proveedor de nube no puede enviar OpenSSL, como ejemplo, y luego señalar con el dedo a algún desafortunado mantenedor de código abierto si las cosas salen mal.

Todavía es temprano, pero es de esperar que esta adopción generalizada de software de código abierto para ofrecer servicios en la nube de orden superior, a su vez, conduzca a contribuciones generalizadas a los proyectos de código abierto de los que dependen estos servicios. Desde el punto de vista de la seguridad, es en beneficio propio de los proveedores de la nube.

Divulgación: trabajo para MongoDB, pero las opiniones expresadas en este documento son mías.

Ver también

Leave a Comment