Si tienes que leer algo estos días, que sea el genial informe que publicaba hace ya unos días el MIT Technology Review (EN) sobre cómo Internet y en líneas generales, toda la economía digital, se levanta sobre aportaciones de personas que no viven de ello.
Un tema del que ya hemos hablado en relación a la creación de contenido (El coste de ese Internet gratuito), y que en esta pieza nos centraremos en el desarrollo.
Algo que hemos visto recientemente ejemplificado en la vulnerabilidad del momento, y que llevamos desde la newsletter de seguridad privada tratando estas últimas semanas:
Volkan Yazici trabaja 22 horas al día de forma gratuita. Es uno de los miembros del proyecto Log4J, una herramienta de código abierto que se utiliza ampliamente para registrar la actividad dentro de varios tipos de software y que ayuda al buen funcionamiento de grandes partes de internet, incluidas muchas apps, desde iCloud a Twitter. Pero Yazici y sus colegas están tratando desesperadamente de lidiar con una vulnerabilidad (EN) masiva que ha puesto en riesgo miles de millones de máquinas.
La vulnerabilidad en Log4J es extremadamente fácil de explotar. Después de enviar una cadena de caracteres maliciosos a una máquina vulnerable, los hackers pueden ejecutar cualquier código que deseen. Algunos de los primeros ataques fueron por parte de unos niños que pegaron el código malicioso en los servidores de Minecraft. Los hackers, incluidos algunos vinculados a China e Irán, buscan explotar (EN) la vulnerabilidad en cualquier máquina que puedan encontrar que ejecute el código defectuoso.
El medio da en clavo cuando señala cómo pese a que Log4j está presente en prácticamente la amplia mayoría de sistemas operativos y servicios que usamos a diario todos nosotros, y que han sido desarrollados por gigantes de la talla de Google, Apple, Microsoft, Facebook o Amazon, el proyecto sigue sin ser rentable económicamente:
Para algo tan importante, uno esperaría que las empresas de tecnología más grandes del mundo y los gobiernos hubieran contratado a cientos de expertos altamente remunerados para repararlo rápidamente. Pero la realidad es muy diferente: Log4J, que ha sido durante mucho tiempo una pieza fundamental de la infraestructura central de internet, se fundó como un proyecto voluntario y todavía se gestiona en gran parte de forma gratuita, a pesar de que muchas empresas de millones y miles de millones de dólares confían en Log4J y se benefician de él todos los días. Yazici y su equipo intentan arreglarlo por casi nada.
Esto, por supuesto, no parece suponer problema alguno cuando las cosas funcionan.
Sin ir más lejos, un servidor empezó hace años realizando colaboraciones para Firefox OS, y por ende donando “mi tiempo” a fundaciones como Mozilla, lo que me acabó permitiendo entrar a trabajar dentro de I+D de Telefónica precisamente con los chicos de Mozilla (Firefox OS acabó siendo un proyecto amparado a partes iguales por Mozilla y Telefónica).
Que es cierto que en el mundo del desarrollo, el colaborar “desinteresadamente” al desarrollo de un software abierto te permite generar currículum con el que, más tarde, conseguir un trabajo o clientes.
Ahora bien, hay un problema claro cuando ese trabajo, que recordemos no está pagado, acaba siendo usado por muchos otros proyectos (abiertos y también cerrados), y alguien encuentra una vulnerabilidad tan grave como ha supuesto (y seguirá suponiendo durante mucho tiempo…) Log4J.
El caso de Log4J no es el único del software libre
En 2018, el programador responsable de un popular proyecto de código abierto ua-parser-js renunció, no estaba dispuesto a trabajar más de forma gratuita. Ese software es también utilizado (EN) por grandes empresas de tecnología como Google, Amazon y Facebook.
A pesar de los muchos miles de programadores que utilizan este software, el proyecto había recaudado solo 36,90 euros en fondos.
No, no me he dejado la palabra “millones”. 37 euros.
Y eso no fue todo.
La persona que tomó el control de ua-parser-js secuestró el software e introdujo código malicioso para robar criptomonedas.
Algo que ya hemos visto pasar en otros derroteros, como el de las apps y extensiones para navegador.
El Departamento de Seguridad Nacional de EE. UU. finalmente emitió una advertencia a los usuarios sobre ese hackeo. El programador original, que cedió libremente el control al sucesor anónimo, calificó la situación de “una locura” (EN). Y no es para menos.
¿Qué solución hay?
Hechas las presentaciones, la duda que me recorre el cuerpo es qué demonios podemos hacer para paliar esta situación.
¿Se debería por ley considerar el software libre una amenaza para la seguridad nacional, y por tanto prohibir su uso, por ejemplo, en infraestructuras críticas?
El problema de esta postura es que, por cómo se entiende hoy en día el desarrollo informático, negar una parte tan core probablemente nos haga retroceder varias décadas a nivel de usabilidad e interconectividad de sistemas.
Algo que, ya de por sí, entraña también riesgos y un coste económico y social más que significativo.
¿Se debería entonces forzar a que las grandes compañías que hacen uso del software libre estén obligadas a financiarlo? Pues se me antoja una buena salida.
Y ojo que en parte ya se está haciendo. Google prometió (EN) recientemente 88,69 millones de euros para respaldar el desarrollo de código abierto y para la solución de las vulnerabilidades. Otro proyecto de Google, el Fondo para la mejora de la tecnología de código abierto (Open Source Technology Improvement Fund), tiene como objetivo auditar (EN) y mejorar los proyectos críticos de código abierto.
La cuestión aquí es que no todo es financiaciación, y problemas como el de Log4J requieren que los proyectos de software libre cuenten con pruebas cuidadosas, ingeniería de versiones, clasificación de problemas, análisis de seguridad, revisión del código de las contribuciones… En definitiva, todo un ecosistema de gestión de proyectos como el que habitualmente hay en una corporación tecnológica, y que frisa de forma frontal con el carácter inicial de muchos de estos proyectos, que nacen precisamente del interés colaborativo de una persona.
En fin, que me temo que problemas como estos nos los iremos encontrando cada vez con mayor intensidad, por eso de que conforme evoluciona la complejidad tecnológica, asumimos mayor riesgo al incluir partes de la cadena cuya gestión no está convenientemente segurizada.
Sea por puro desconocimiento, sea por falta de recursos, sea por ambas cosas.
Imagínate recibir en tu correo semanalmente historias como esta
Suscríbete ahora a “Las 7 de la Semana”, la newsletter sobre Nuevas Tecnologías y Seguridad de la Información. Cada lunes a las 7AM horario español un resumen con todo lo importante de estos últimos días.
¿22 horas al día???? pero entonces no duerme, no sale con los amigos, no se hace la comida, no se ducha, no limpia la casa…….
Esas son cosas de perdedores Gonzalo G.G
Pero al final, abierto ono, trabajando gratis o no, no deja de ser software código abierto. Si grandes empresas multimillonarias deciden utilizarlo lo hacen asumiendo ese riesgo.
Además tampoco hay garantías cuando el software es de pago, donde la mayor parte de las veces, lo que se obtiene es una licencia y tampoco hay garantías de nada. Los disclaimers de muchas licencias son hermosisimos
El hecho de que existan proyectos de este tipo son dados a esto. Pero estoy seguro que también hay dependencias de software que hace años que no tienen soporte porque el desarrollo murio, pero se siguen utilizando cosas y que tarde o temprano saldrán a la luz.
Pero vamos, creo que es lo que hay, la tecnología se ha creado, ha evolucionado y crecido en base a estas premisas. Y da igual si es un software abierto o cerrado, si el desarrollador ha cobrado o ha tenido que poner dinero de su bolsillo, cuando vienen mal dadas la responsabilidad es tuya
Por eso decía que le veo poca solución.
El dinero ayuda, por supuesto, pero al final hablamos en muchos casos de proyectos que nacen de propuestas e intereses de una persona en particular, y que es normal que acaben en saco roto. ¿Que hay dinero de por medio? Pues quizás se alargue un poco más el ciclo de soporte. Pero poco más…