Protestware: Developers Sabotaging Their Own Code

Protestware

What is Protestware?

code-computer

We can talk about the concept of **Protestware** as a growing trend in recent years. We refer to this term as the **actions taken by developers to sabotage their own libraries, code, and/or send protest messages through them**. Thus, this practice, beyond corrupting the code, has also become a way to express opinions on current issues such as crises, wars, or political situations, potentially causing massive collateral damage.

We understand the benefits of shared access to source code for developers, whose origins date back to the communities of **Open Source Software**. However, it is also known that this term brought confusion between freedom and gratuity.

Some Examples

As an example of **Protestware**, we can mention the case of *Markus Unterwaditzer*, the developer of the [Python Atomicwrites library](https://python-atomicwrites.readthedocs.io/en/latest/#), who **deleted his code from the PyPI package repository** upon learning that they were going to require two-factor authentication to ensure SOC2 compliance in companies using that code.

Also famous was the incident of developer *Azer Koçulu*, who **deleted his code and briefly broke a large part of the Internet by including the Left-Pad Library**. *Koçulu* justified the sabotage because in a trademark registration dispute between his *npm* package called *Kik*, and a messaging brand with the same name, *npm* sided with the company, prompting the developer to remove all his code.

In January of this year, developer *Marak Squires* **deliberately corrupted two Open Source libraries (colors and faker) that he himself had created**. Numerous applications using these libraries started failing, returning inconsistent data, strange messages, and contaminated versions. This self-sabotage on GitHub, whose libraries were used for free by numerous companies in thousands of applications for their projects and apps, sparked a debate among developers. The reasons he did this were clear: he was tired of these large corporations, some even in the Fortune 500 index, using them without him receiving any payment or benefit for his work.

A group of Open Source developers using the *faker* library **decided to take responsibility for it and turn it into a community-controlled project**. That is, some members supported *Marak Squires’* decision, even diverting some of the project’s funding to him, so he could continue supporting its development. However, other community members were outraged, as GitHub suspended the developer’s account with over 100 projects, and they questioned whether continuing on GitHub would mean depositing their work selflessly on a platform that other companies use and exploit without offering practically anything in return.

Also in 2022, developers have **sabotaged their own libraries to protest against large corporations and even the Ukraine-Russia war**.

Self-sabotage? Protest? Growing Trend?

wocu-monitoring

The conclusion we can draw is that the **Protestware** trend is not easy to judge because, despite the massive impact it can have on projects under a peaceful protest goal, it can also **damage the image and trust of the Open Source developer community**.

Likewise, these protests put platforms like GitHub, Gitlab, or Bitbucket in a difficult position: on the one hand, allowing that freedom of expression to developers using their platform to support causes they believe in, or taking responsibility to ensure to their users that code repositories are free of malicious code, even deleting the code in question if necessary.

Prevention, Detection, and Mitigation of Risks

To prevent such situations, during the development and deployment process, it is necessary to **appropriately pin the versions of third-party libraries**. This way, we prevent a new version published by an external library from affecting the entire software we distribute.

When maintaining a new library (or updating its version), numerous tests must be performed for the change to be accepted. For this, a good practice we follow at **WOCU-Monitoring** is to have a set of [integration and deployment pipelines (CI/CD)](https://www.wocu-monitoring.com/noticias/wocu_dependencias_ci/).

dependencias-CI

In these pipelines, multiple tasks can be performed such as dependency scanning, static code analysis, detection of secrets, dead code, SAST, DAST, or vulnerability analysis in dependencies, among others. At **WOCU-Monitoring**, we are particularly **committed to the security of the code** (both ours and third-party).

No software is exempt from security flaws, as we experienced several months ago with a vulnerability found in a third-party library ([XSS vulnerability in TinyMC](https://www.wocu-monitoring.com/noticias/analisis_vulnerabilidad_xss_en_wocu/)), but it is our responsibility to control, minimize, and react to these situations as quickly as possible.

Request your demo today and discover how to take control of your infrastructure.

Request a DEMO

Free edition

Enjoy all the features of Wocu-Monitoring, including support at no cost.

Contact

What to do next?

We want to be your great ally to achieve your corporate challenges.

Ready to witness the digital impact on your business?