¿Qué es el Protestware?
Podemos hablar del concepto Protestware como una tendencia que en los últimos años se encuentra en auge. Nos referimos con este término a las acciones que llevan a cabo los desarrolladores para sabotear sus propias librerías, código y/o enviar mensajes de protesta a través de ellos. Así pues, esta práctica, más allá de corromper el código, se ha convertido también en una manera de opinar sobre temas de actualidad como pueden ser las crisis, guerras o situaciones políticas, pudiendo causar daños colaterales masivos.
Sabemos lo beneficioso que resulta el acceso compartido al código fuente para los desarrolladores, cuyo origen se remonta a las comunidades de Software Libre. Pero también, es conocido que este término trajo consigo la confusión de libertad con gratuidad.
Algunos ejemplos
Como ejemplo de Protestware, podemos nombrar el caso de Markus Unterwaditzer, desarrollador de la biblioteca Python Atomicwrites, quien borró su código del repositorio de paquetes PyPI al enterarse de que iban a exigir la autenticación de dos factores para garantizar el cumplimiento de SOC2 en las empresas que utilizaban dicho código.
También fue célebre el incidente del desarrollador Azer Koçulu, que eliminó su código y rompió por un momento una gran parte de Internet al incluir la Biblioteca de Teclado Izquierdo (paquete de almohadilla izquierda). Koçulu justificó el sabotaje porque en una disputa de registro de marca entre su paquete npm llamado Kik, y una marca de mensajería con el mismo nombre, npm dio la razón a la empresa, motivo por el que el desarrollador retiró todo su código.
En enero de este año, el desarrollador Marak Squires corrompió deliberadamente dos librerías Open Source (colors y faker) que él mismo había creado. Multitud de aplicaciones que utilizaban dichas librerías empezaron a fallar, devolviendo datos incoherentes, mensajes extraños y versiones contaminadas. Este autosaboteo en GitHub, cuyas librerías utilizaban gratis numerosas empresas en miles de aplicaciones para sus proyectos y apps, generó un debate en el entorno de los desarrolladores. Los motivos por los que lo hizo fueron claros: estaba harto de que estas grandes corporaciones, algunas incluso en el índice Fortune 500, las utilizasen sin él recibir ningún pago o beneficio subrogado por su trabajo.
Un grupo de desarrolladores Open Source que utilizaban la librería faker decidió responsabilizarse de ella y convertirla en un proyecto controlado por la comunidad. Es decir, algunos miembros apoyaron la decisión de Marak Squires, incluso desviaron parte de la financiación del proyecto para donárselo a él, para que pudiera seguir dando soporte a su desarrollo. Sin embargo, otros miembros de la comunidad se indignaron, ya que GitHub suspendió la cuenta del desarrollador con más de 100 proyectos y valoraron si al continuar en GitHub significaría depositar su trabajo de forma desinteresada en una plataforma que otras empresas usan y explotan sin ofrecer prácticamente nada a cambio.
También en este 2022, desarrolladores han saboteado sus propias bibliotecas para protestar contra las grandes corporaciones e incluso por la guerra Ucrania-Rusia.
¿Autosabotaje? ¿Protesta? ¿Tendencia en auge?
La conclusión que podemos extraer es que la tendencia Protestware no es sencilla de juzgar porque, pese a la afectación masiva que puede llegar a provocar en los proyectos bajo un fin pacífico de protesta, también puede dañar la imagen y confianza de la comunidad de desarrolladores de código abierto.
Asimismo, estas protestas colocan a GitHub y otras plataformas como Gitlab o Bitbucket en una difícil decisión: por un lado, permitir esa libertad de expresión a los desarrolladores que usan su plataforma para apoyar las causas en las que creen, o hacerse responsable ante sus usuarios de garantizar que los repositorios de código estén libres de código malicioso, eliminando incluso si fuera necesario el código en cuestión.
Prevención, detección y mitigación de riesgos
Para evitar este tipo de situaciones, durante el proceso de desarrollo y despliegue es necesario fijar apropiadamente las versiones de las librerías de terceros. De este modo, evitamos que una nueva versión publicada de una librería externa pueda afectar al conjunto del software que distribuimos.
A la hora de mantener una nueva librería (o para actualizar su versión) se deben pasar numerosas pruebas para que el cambio sea aceptado. Para ello, una buena práctica que seguimos en WOCU-Monitoring, es tener un conjunto de pipelines de integración y despliegue (CI/CD).
En dichos pipelines se pueden realizar múltiples tareas como escaneos de dependencias, análisis estático del código, detección de secretos, código muerto, SAST, DAST, o análisis de vulnerabilidades en dependencias, entre otros. En WOCU-Monitoring estamos especialmente comprometidos con la seguridad del código (tanto nuestro como de terceros)
Ningún software está exento de tener fallos de seguridad, como nos ocurrió hace varios meses con una vulnerabilidad encontrada en una librería de terceros (vulnerabilidad de XSS en TinyMC), pero es nuestra responsabilidad controlar, minimizar y reaccionar ante estas situaciones de la forma más rápida posible.
Pide hoy tu demo y descubre cómo tomar el control de tu infraestructura.
