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.”

Census II es el primer estudio importante de este tipo, pero no es un análisis final. Siendo más concretos, da los primeros pasos importantes y presenta una metodología para comprender y abordar las complejidades estructurales y de seguridad del software Open Source, además de identificar lo que se ha mencionado en el párrafo anterior.

¿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.

Además, y siguiendo la línea del informe publicado hace poco por Red Hat, se recalca la cada vez mayor importancia del FLOSS en el mundo empresarial. Frank Nagle, profesor de la Escuela de Negocios de Harvard y codirector del informe Census II, ha comentado que “el FLOSS fue visto por mucho tiempo como el dominio de los aficionados y manitas de la computación. Sin embargo, ahora se ha convertido en un componente integral de la economía moderna y fundamental de las tecnologías cotidianas como teléfonos inteligentes, automóviles, Internet de las cosas y numerosas piezas de infraestructura crítica. Comprender qué componentes son los más utilizados y los más vulnerables nos permitirá ayudar a garantizar la salud continua del ecosistema y la economía digital.”

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 componentes más usados que no están hechos con JavaScript:

• Com.fasterxml.jackson.core:jackson-core: Una parte central de Jackson, un procesador JSON (JavaScript Object Notation) que define la API Streaming y las abstracciones básicas compartidas.
• Com.fasterxml.jackson.core:jackson-databind: Paquete general de enlace de datos para Jackson (2.x). Funciona en implementaciones de API de transmisión.
• Com.google.guava:guava: Bibliotecas principales de Google para Java.
• Commons-codec: El software Apache Commons-Codec proporciona implementaciones de codificadores y decodificadores comunes como Base64, Hex, Fonética y URL.
• Commons-io: Commons IO es una biblioteca de utilidades para ayudar con el desarrollo de la funcionalidad entrada-salida.
• Httpcomponents-client: El proyecto Apache HttpComponents es un conjunto de herramientas de componentes Java de bajo nivel centrados en HTTP y protocolos asociados.
• Httpcomponents-core: Lo mismos que el anterior.
• Logback-core: El marco de registro confiable, genérico, rápido y flexible para Java.
• Org.apache.commons: commons-lang3: Un paquete de clases de utilidad Java para las clases que están en la jerarquía de java.lang, o que se consideran tan estándar como para justificar la existencia en java.lang.
• Slf4j: Fachada de registro simple para Java.

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.

El punto expuesto en el párrafo anterior tampoco es que sea una sorpresa, sino que ya se ha visto en otras ocasiones, como por ejemplo en GitHub, donde un porcentaje importante de los contribuidores a los proyectos más relevantes proceden de grandes corporaciones como Microsoft. No, el Open Source ya no es un “movimiento rebelde”, sino que se ha consolidado como un motor importante de muchas grandes empresas del mundo.

Por otro lado, los investigadores han encontrado diversos problemas comunes entre en los componentes Open Source. El primero de estos es la falta de un esquema de nomenclatura estandarizado para los componentes de software, que hace que el seguimiento de estos programas sea un gran problema.

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.

Está claro que las cuentas de desarrolladores individuales necesitan más protección de la que tienen. El programa de identificación CII de la Fundación Linux y Trust and Security Initiative incorporan la seguridad de la cuenta del desarrollador en sus controles para mitigar estos riesgos.

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.