La responsabilidad de un desarrollador FOSS

Un suceso desastroso

Durante el mes de Diciembre de 2021, han surgido varias incidencias críticas de seguridad en uno de los frameworks más usados en Java: Log4j.

Log4j es una biblioteca hecha en lenguaje Java destinado a la presentación de logs en una aplicación de dicho lenguaje y, actualmente, un gran número de aplicaciones y servicios están usándolo. Un fallo en esa parte puede causar un problema global, tal como se está viendo.

Las vulnerabilidades críticas descubiertas son las siguientes:

• CVE-2021-44228 - gravedad 10 - descubierto el 10/12
• CVE-2021-4104 - gravedad 8.1 - descubierto el 14/12
• CVE-2021-45046 - gravedad 9.0 - descubierto el 14/12
• CVE-2021-45105 - gravedad 7.5 - descubierto el 18/12

Así que, si eres desarrollador y usas Log4j, te va a tocar resolverlo o ya has tenido que aplicar las soluciones dispuestas (mediante actualización de la biblioteca, mitigaciones o buscando otra biblioteca que la sustituya).

La crítica sin control y los memes

Tras este desastre mayúsculo, no falta gente que se lo toma con humor y lo muestra con memes como el que muestro aquí abajo y tampoco faltan personas que ponen el grito en el cielo con mensajes del tipo "Qué desarrolladores más incompetentes", "Seguro que no hacen tests unitarios" o "¿Cómo narices una biblioteca de logging tiene cuatro vulnerabilidades críticas de seguridad?".

Pero hay una cosa que a los críticos de Internet (posiblemente afectados por dicho problema) se les olvida: es una biblioteca de uso gratuito, en la que no se está pagando por el soporte y mantenimiento, con autorización de poder analizar o modificar el código por nuestra parte y mantenida por una organización non-profit (Apache) que se mantiene económicamente con donaciones de empresas y particulares.

Hay que tener la osadía y la poca vergüenza de exigir (no pedir, exigir) la reparación inmediata y urgente del fallo en un producto por el que usas de forma gratuita (salvo que estéis pagando al desarrollador el soporte).

Entonces, ¿quién es el responsable?

Mi respuesta va a doler (y me dolería igual si estuviese en vuestro lugar): la responsabilidad en la cual el fallo afecte a vuestro proyecto es únicamente vuestra. Los desarrolladores de Log4j son responsables del fallo en su parte (y bastante gordo es el fallo que tienen), pero no son responsables de cómo habéis integrado su biblioteca en vuestro proyecto ni de las consecuencias derivadas de ello.

Si vuestro desarrollo de software tiene un fuerte acoplamiento con bibliotecas de terceros que impide que puedas cambiar de biblioteca o aplicar medidas propias de mitigación, es un fallo de desarrollo por vuestra parte. No hay más.

Hay que tener en cuenta que a la hora de añadir una biblioteca externa, se deben aplicar medidas que permitan retirar dicho software de tu proyecto en cualquier momento; ya sea por problemas de funcionamiento o porque ha llegado al final de su utilidad.

Conclusión

Para concluir, os indico unos puntos a tener en cuenta:

• Evita integrar bibliotecas sin ninguna justificación para ello. No es buena idea integrar un módulo para algo que puedes hacer tú en poco tiempo (si tienes un desarrollo en NodeJS, lo comprenderás -> node_modules).

• Evita acoplar tu proyecto a las bibliotecas que integres. Haz una abstracción y así no tendrás problemas cuando necesites cambiarlas o retirarlas.

• Si usas bibliotecas FOSS y encuentras un fallo o problema, comunícalo y, si sabes solucionarlo, presenta un fix. No obstante, ve preparando un plan B en caso de no recibir respuesta.

• Recuerda que una parte considerable de desarrolladores de un proyecto FOSS suelen trabajar por amor al arte, así que no está de más ser un poco considerado a la hora de reportar fallos.

• Por último, si el trabajo de ese desarrollo aporta mucho a tu proyecto, busca si se puede pagar un servicio de soporte al desarrollador o, como mínimo, aportar económicamente o en código a dicho proyecto. Al final, si ese proyecto externo mejora, el tuyo también lo hará.