The Promise of Open Source Code and the Paradox of ‘ProtestWare’

The Open Source Software (OSS) community has been split in two after an OSS author repurposed his own library to protest the Ukrainian-Russian war. On March 7, RIAEvangelist released several versions of his “node-ipc” software package—which has been downloaded millions of times—with some versions reportedly overwriting code on machines presumably located in Russia and Belarus.

About one module, called peacenotwar, RIAEvangallist, wrote:

This code serves as a non-destructive example of why controlling your node modules is important. It also serves as a non-violent protest against Russia’s aggression that threatens the world right now. This module will add a message of peace on your users’ desktops, and it will only do it if it does not already exist just to be polite.

His actions—i.e. “deliberately sabotaging his own code”—have sparked a massive controversy while giving birth to a new surge of “protestware,” where other hacktivist  developers may target Russian-based machines. 

The Open Source community was formed on the ideals of improving software, skills, and empowering change. By that definition, you can argue that RIAEvangelist, whose given name is Brandon Nozaki Miller, is pushing for change. At the same time, however, the community does not tolerate bad actors. Does node-ipc’s changes fulfill or neglect the ideals that led to the creation of the Open Source community? That is up to the community to decide.

Potential fallout of protestware 

The node-ipc event has led to the coining of “protestware” and its aftermath may inspire other developers to follow suit. Russia’s largest bank in particular is wary of this as they have advised its customers to avoid updating computer programs, or insisting them to manually check the source code of any open source project.

If this trend continues it can lead to a slippery slope as OSS is supposed to help. Nearly every industry has adopted technology so therefore, the foundations of countless organizations’ systems and products run on OSS. If other authors, owners, and maintainers choose to morph their projects into protestware there is a high chance that many organizations will become collateral damage. And if people cannot trust Open Source, then theoretically the community could fall apart.

A community split in two

Were RIAEvanglist’s actions malicious? Depending on who you ask, some might say that there was nothing wrong about his intentions:

Some like the GitHub user above, as well as RIAEvangelist himself, stand by his decision. However, the opinion that most in the community have is that his actions are a massive blow to the credibility and trust of OSS:

A few have also come forward claiming that RIAEvangelist’s actions have had direct consequences on their businesses. On March 17, a user claiming to represent an American Non-Government Organization stated that node-ipc allegedly wiped over 30,000 of their messages and files detailing Russian war crimes committed against Ukraine.

While the authenticity of this claim is disputed, it does highlight that IP-based attribution is not reliable. Just because a machine’s IP is located in a certain country, it doesn’t mean that it is directly controlled by them. Initiating malware by country code could do more harm than good, impacting Russian or Belarusian organizations that are fully and publicly against the war.

Current state of open source software

When it comes to Open Source Software, everyone (seemingly) benefits. Technologists get to work on passion projects that they get to control, while also gaining status if it becomes widely used. Hobbyists gain access to code that they might not be able to write themselves, and get to learn from the best in the industry. And for corporations, they get to use (mostly) reliable and tested code for free, saving them considerable time and money.

As such, OSS has become integral to the development process for organizations, allowing development teams to push products to market faster. These days, vendors are releasing products that contain hundreds or even thousands of open source components, and nearly all of them are needed to function properly. This practice has gone on for decades, which has made nearly every industry reliant on OSS code and dependencies—creating tons of security concerns.

You are what you consume

There are risks when using OSS. For starters, many vendors and organizations aren’t keeping track of which OSS components are being used in their products. Indiscriminate consumption of OSS can lead to possible lawsuits if organizations unknowingly use licensed code. But more importantly, not knowing which libraries are bundled makes it near impossible to keep them up-to-date, or to detect the vulnerabilities inside of them.

Products can inherit vulnerabilities contained in OSS code and if exploited, these issues can give malicious actors an open door into even the largest organizations. In addition to vulnerabilities, other third-parties could attempt to add malicious updates, or try typosquatting—tricking organizations to download fake versions of popular libraries.

Understanding node-ipc

In terms of tampering, node-ipc did two things. The first is overwriting code for Russian and Belarus-based machines, and the second is the “peacenotwar” package. However, the most important takeaway is that current versions of node-ipc do not overwrite code.

What organizations can do for OSS security

If situations like the Node-ipc incident were to become common, organizations would have three options:

• Simply accept current risk and operate as they are
• Adopt certain OSS libraries and maintain it moving forward
• Forego OSS entirely and write their own code

1. Operate as normal, accepting possible risk

By and large, this is the current state of Open Source security, and if you want proof, you’d only have to look at  struts-shock, heartbleed, and log4shell. All of these were OSS vulnerabilities that had major impacts on organizations. And despite some of these issues existing for years, undiscovered in open code, most organizations still choose to indiscriminately consume open source components.

Enterprises should at least create a Software Bill of Materials (SBOM) to keep tabs on the various OSS components being used in their deployed software. Doing this will help their security teams track vulnerabilities affecting third-party libraries and dependencies. It can also help prevent developers falling for typo-squatting attempts.

However this won’t do much in situations in which the perpetrator is the author, owner, or maintainer for a third-party library. There are a few examples of where authors delete or sabotage their own code due to burnout or being wronged in some way. And when this happens, it can create chaos potentially giving malicious actors an opportunity to capitalize.

2. Adopt OSS libraries and self-maintain

To lessen the impact that one developer can have, organizations may want to consider forking the OSS libraries they use and maintain them internally moving forward. Although this is likely the best option in some cases, it will require a SBOM and a significant amount of resources.

One product often contains hundreds of bundled libraries so depending on how much software is deployed, this will likely be an incredible undertaking. There are few organizations that can dedicate personnel to accomplish this and even if they tried, there are too many libraries for one team to track and monitor. If some organizations are having trouble checking release notes, it is very likely that they will not be able to take the time to audit newly released code.

3. Write code independently

This method requires the most time and resources and will likely never happen for many organizations. There is a reason why organizations choose to use OSS for their products. Production cycles have become incredibly short and are very demanding. Adding more custom code that performs critical functionality makes this more difficult. As such, reliance on OSS will never cease.

Take control by understanding cost of ownership

Maybe Node-ipc will be the watershed moment that makes organizations realize the risks that OSS can introduce. That is uncertain, but what is certain is that the work done by technologists often goes unthanked. Whenever issues go wrong with third-party libraries and dependencies, those who aren’t in the know tend to place the blame directly on the project.

We don’t often think about the scope of most OSS projects. According to a report, many of the top 500 most used free and open-source software projects are listed under a single developer’s personal account. Most OSS is written and maintained by one or a small group of enthusiasts in their spare time, so is it fair to hold them accountable for the security of thousands of organizations? These are usually unpaid, passion projects and if things go wrong they have to fix it off the clock.

Like CVE wasn’t intended to be the vulnerability bible, OSS software wasn’t supposed to be massively consumed by corporations. To avoid the ramifications of a developer going rogue, organizations should take ownership of their own security. And to do that, they will need to take SBOMs seriously and use quality vulnerability intelligence to understand the cost of ownership for the products they deploy.

Detect, prioritize, and remediate risks faster

In order to detect risk in Open Source Software and dependencies, organizations need quality vulnerability intelligence. Flashpoint tracks and monitors thousands of third-party libraries. Sign up for a free trial and learn more today.