software libre

Este es una de las newsletters antiguas que se enviaron de forma exclusiva a los miembros del Club Negocios Seguros.


Si quieres recibir las actuales cada martes y jueves en tu bandeja de correo, hazte miembro ahora.

*******

Negocios Seguros

Newsletter 874

********

Dos noticias me llevan a escribir esta pieza.

Como diría Jack el Destripador, vamos por partes G.G


Los límites del software libre

A estas alturas creo que la mayoría estaremos de acuerdo de que el software libre ha demostrado ser uno de los paradigmas de desarrollo que más han aportado a la sociedad.

Es más, como dejábamos claro recientemente en un articulo, buena parte del software propietario exitoso actual se levanta bajo el esqueleto de proyectos gestionados por la comunidad. Que si casi todos los firmwares de infraestructura de red, que si Android y su hegemónica presencia… El propio MacOS y las versiones para dispositivos móviles de Apple no dejan de partir de UNIX…

¿Por qué ocurre esto?

Pues porque el software libre funciona precisamente en base a la popularidad y el compromiso de unos muchos. Es, en esencia, el máximo exponente de la solidaridad informática.

Conforme más interesante sea para la comunidad, mayor número de ojos y manos estarán puestos en él. Y por tanto, mayor capacidad de evolución y menor impacto de potenciales vulnerabilidades puede llegar a sufrir.

O esto al menos es la teoría, porque como te decía, en la ecuación no solo está la importancia o valor que ofrece dicho software, sino también su popularidad… y asociado a esta, la gestión que se haga del proyecto.

Así, esa suerte de pilares robustos que han hecho grandes al software libre pueden, casi de la noche a la mañana, dilapidarse por completo.


¿Que por qué?

Pues porque del software libre rara vez se vive. Y los humanos tenemos la dichosa costumbre de querer comer cada día. ¡Incluso varias veces al día!

Así, no es raro que herramientas de software libre CRÍTICAS para el funcionamiento de todo el ecosistema pasen, de un día a otro, a no estar gestionadas. Simplemente porque su creador, o el grupo principal de desarrolladores encargados de mantener y actualizar las herramientas, han pasado a estar a otra cosa.

Que si han encontrado trabajo (probablemente, de hecho, gracias a haber demostrado ese compromiso y ese expertise con el proyecto), que si simplemente están en otro momento de su vida, con otras prioridades.

Lo vivimos en primera persona, de hecho, el año pasado, cuando saltó a la palestra la vulnerabilidad de Log4J. Ya te conté la historia por el blog, pero por resumirlo muy mucho, hablamos de un problema gordísimo de seguridad para casi toda la industria debido a un componente que había sido desarrollado por una sola persona. Esta persona (y el escaso grupo que le ayudaba) se cansó de trabajar GRATIS para que gigantes como Google o Apple se lucraran con su desarrollo, y de la noche a la mañana decidió abandonar el proyecto sin parchear.

El informe anteriormente citado llegaba a la conclusión de que de esos 1,2 millones de proyectos de software de código abierto analizados, tan solo el 11% recibían un mantenimiento mínimo para asegurar su futuro.

De hecho, se calcula que de todos los problemas de seguridad a los que cualquiera de nosotros estamos expuestos, el 10% se deben precisamente a esto: a que alguna de las piezas de la cadena depende de una comunidad y un proyecto de código abierto que no está siendo auditado y mantenido.


El ejemplo de Linux

De todos los grandes proyectos, quizás el del sistema operativo Linux sea el más conocido por todos.

Presente en prácticamente todos los dispositivos IoT de la actualidad (tu router incluido, sí), y con una de las mayores comunidades de entusiastas del código abierto, se enfrenta ante la difícil tesitura de su crecimiento versus al interés que puede tener alguien en dedicarse a mantenerlo y parchearlo.

Solo en estos últimos días, y que yo me haya enterado, han aparecido dos nuevas vulnerabilidades gordas.

  • Un error de seguridad en la biblioteca Libcue que afecta a todas las últimas versiones de GNOME, el entorno de escritorio más popular de Linux (Debian, Ubuntu, Fedora y un largo etcétera de distros lo usan).
  • Un paquete infectado que se coló en el Free Download Manager de Debian, con todo lo que eso supone (miles de usuarios han sido infectados sin saberlo).

¿Pasa lo mismo con Windows y MacOS?

Por supuesto. La diferencia es que en estos casos hay alicientes económicos para buscar la solución y el parche lo antes posible.

Con el software libre… pues depende. Al no soler haber alicientes económicos, dependemos tanto de la buena fe como del compromiso de sus desarrolladores. Muchos de ellos más interesados en ofrecer nuevas funcionalidades (queda mucho más molón en el currículum) que de pegarse con parchear lo que está fallando.

Y no hay una solución clara

Ya lo comentaba cuando ocurrió lo de Log4j.

La única solución que se me ocurre es forzar de alguna manera a las grandes tecnológicas, que son a fin de cuentas los principales interesados en que estos desarrollos sigan funcionando, a dedicar recursos a su mantenimiento.

Claro que es más fácil decirlo que hacerlo, ya que entonces ¿dónde ponemos los límites operativos e interdependientes?

En un entorno tan complejo como es el actual, ¿Estaría una empresa como Amazon obligada por ley a destinar recursos a buena parte de la totalidad de software libre que se ha creado por el simple hecho de que alguno de sus servicios usa algún componente del mismo? ¿Y si quien lo usa es ese componente (es decir, la relación es en un segundo nivel, o en un tercero…)?

________

Si quieres recibir contenido exclusivo como éste el día uno y directamente en tu bandeja de correo cada martes y jueves, hazte miembro del Club «NEGOCIOS SEGUROS».

Banner negocios seguros