The Linux Foundation identifica los componentes Open Source más utilizados para mejorar su seg

The Linux Foundation ha publicado su informe Census II, con el pretende identificar “los componentes de software libre y de código abierto (FLOSS) más utilizados en aplicaciones de producción y comenzar a examinarlos para detectar posibles vulnerabilidades.” ¿Cuáles son los proyectos Open Source más populares? Para la elaboración del informe, Core Infrastructure Initiative (CII) y el Laboratorio para Ciencia de Innovación de Harvard (LISH) han unido sus fuerzas con empresas de seguridad como Snyk y Synopsys Cybersecurity Research Center para combinar datos de uso privado con otros públicamente para identificar más de 200 de los proyectos de software Open Source más utilizados, los cuales han sido divididos en dos categorías: los que se basan en JavaScript y los que no. Los primeros cobran especial relevancia debido al ecosistema NPM, que contiene decenas de componentes que han sido escritos con unas pocas decenas de líneas de código de JavaScript y en muchos casos sin que haya funciones declaradas. Curiosamente, aquí no se encuentran pedazos de software populares como podrían serlo Linux, Apache y MySQL, por nombrar tres ejemplos socorridos. Aunque los grandes proyectos suelen acaparar el protagonismo, el hecho de no poner un ojo supervisando proyectos aparentemente más pequeños puede terminar teniendo consecuencias catastróficas. Esto se vio hace unos años con el caso de Heartbleed, la vulnerabilidad hallada en OpenSSL que dejó en pañales toda la web. Dicha situación obligó a mover fichas para que la biblioteca criptográfica tuviera un mantenimiento y una supervisión correctos, ya que el código abierto no proporciona seguridad de por el hecho de serlo, si bien la mayor transparencia ayuda en la detección de vulnerabilidades y permite auditar código sin compromisos.

A pesar de que el Open Source lleva tiempo intentando penetrar en el mercado de masas, donde tiene actualmente su principal nicho es en los desarrolladores, que muchas veces descubren un software y luego deciden descargarlo e implementarlo en los prototipos de sus proyectos. Aquí es importante tener en cuenta el ecosistema de NPM, donde el 47% de los paquetes tienen entre 0 y 1 funciones, siendo la media del total 112 líneas de código en JavaScript. Esto no solo pone de relieve el pequeño tamaño de los proyectos con los que suelen trabajar muchos desarrolladores, sino que contrasta con las 2.232 líneas de código que tiene de media un módulo de Python alojados en el repositorio PyPI. Sin más dilación, vamos a mencionar los componentes de software Open Source más utilizados en cada una de las categorías establecidas por el estudio.

Programas de JavaScript más usados:

- Async: Un módulo de utilidad que proporciona funciones para trabajar con JavaScript asíncrono. Aunque originalmente se diseñó para ser uado con Node.js y se puede instalar a través del comando “npm install async”, es posible usarlo directamente en el navegador.

- Inherits: Herencia amigable con el navegador totalmente compatible con las herencias del node.js estándar.

- Isarray: Matriz para navegadores más antiguos y versiones obsoletas de Node.js.

- Kind-of: Obtiene el tipo nativo de JavaScript de un valor.

- Lodash: Una moderna biblioteca de utilidades de JavaScript que ofrece modularidad, rendimiento y extras.

- Minimist: Opciones de argumento de análisis.

- Natives: Llama a los módulos JavaScript nativos de Node.js.

- Qs: Una biblioteca de parseo y conversación a string de cadenas de consulta con cierta seguridad adicional.

- Readable-stream:: Flujos principales de Node.js para el espacio de usuario.

- String_decoder:: Node-core string_decoder para el espacio de usuario.

Los principales problemas en el Open Source

Los investigadores tras el informe descubrieron que el mito del desarrollador único de código abierto que trabaja por amor al arte es solo eso: un mito. Un programador puede comenzar en casa, pero no se queda ahí a menos que le guste su oficina en casa. En lugar de eso, lo que se plasma en el informe Census II es una alta correlación entre estar empleado y ser uno de los principales contribuyentes a los paquetes FOSS más populares.

The Linux Foundation y sus socios creen que existe una “necesidad crítica de crear un esquema de denominación de componentes de software estandarizado. Hasta que exista, las estrategias para la seguridad del software, la transparencia y más tendrán un efecto limitado. Las organizaciones seguirán siendo categóricamente incapaces de comunicarse entre sí”, algo a lo que suma “la frecuencia y la sofisticación crecientes de los incidentes de ciberseguridad en los que la cadena de suministro de software juega un papel importante.”

El segundo problema es que muchos de estos programas viven de la mano de desarrolladores individuales. “De los diez paquetes de software más utilizados en nuestro análisis, el equipo de CII descubrió que siete estaban alojados en cuentas de desarrolladores individuales”. ¿Qué sucede si una de estas cuentas es hackeada? Lastimosamente, aquí hay ejemplos de proyectos que han acabado mal debido al hackeo de la cuenta de sus propietarios, que eran personas individuales.

Por ejemplo, un programa de Node.js llamado left-pad fue eliminado por su desarrollador, provocando que miles de programas JavaScript npm fallaran. Otro ejemplo fue el hecho de que un hacker obtuvo acceso a la popular biblioteca de JavaScript Event-Stream y colocó una puerta trasera en el código. Luego agregó código malicioso en la biblioteca, lo que le permitió robar Bitcoin.

El último problema es que el código abierto no ha escapado a la maldición del software heredado o software legacy. Los desarrolladores pasan a programas más nuevos o versiones más nuevas de sus programas anteriores, pero muchos programadores todavía dependen del programa anterior. Estos desarrolladores son reacios a moverse cuando el nuevo paquete de reemplazo generalmente hace el mismo trabajo. Esto es especialmente cierto cuando el nuevo componentes viene, como a menudo pasa, con errores de compatibilidad. Para solventa esto los desarrolladores que usan Open Source deben comenzar a abordar los problemas del software legacy, cosa que puede resultar engorrosa o plomiza, pero muy necesaria para mantener la seguridad.

Por lo que se puede ver, los grandes retos de seguridad en el Open Source podrían no estar tanto en los grandes proyectos como en los pequeños. Esto puede recordar un poco a la situación de la seguridad en las empresas, y es que si bien las grandes corporaciones pueden ser objetivos más tentadores o que pueden reportar más beneficios para los actores maliciosos, son las pymes las que tienen las infraestructuras más endebles frente a las ciberamenazas.

Fuente : linuxblog