Protestware: What Organizations Need to Know When Using Open Source Software


The recent inclusion of “protestware” in popular open source software (OSS) codebases highlights some emerging risks for organizations that rely on OSS.

Keys to go

There have been recent incidents of incorporation of “protestware” or malicious code into open source software (OSS) codebases.

Organizations that rely on business-critical software that contains open-source software can be exposed to business and security risks.

Organizations should implement policies and procedures to further mitigate the risks associated with the use of open source software.

Open-source software (SSO) is ubiquitous in commercial software. Both internal and external developers use community code from public repositories like GitHub to build, test, release, and maintain software more efficiently. This shortens publication times and helps organizations gain a competitive advantage.

While the OSS community generally operates as a quality control gatekeeper, the volume and widespread use of OSS means that there are still risks associated with its use.

On March 8, 2022, the maintainer of node-ipc, an OSS JavaScript library downloaded approximately one million times per week, released an update containing “protestware”. The release included obfuscated code that determined the approximate location of machines running the software. If the IP address was geocoded in Russian or Belarusian, the software traversed the user’s file system, overwriting any data encountered with heart symbols. The maintainer defended its additions to the module as a protest against Russia’s invasion of Ukraine.

Director of Developer Advocacy at Developer Security Platform ‘Snyk’, who investigated and disclosed the incident, observed that it highlights ‘a larger problem facing the software supply chain: transitive dependencies in your code can have a huge impact on your security”. Not surprisingly, the node-ipc protest software implementation affected more than the intended targets – later reports claimed that a US NGO operating a production server in Belarus had been affected.

This is just one example of recent OSS software protests and other OSS-related incidents. In January, the maintainer of two open-source libraries (with over 3.5 billion total downloads combined) released an update that, among other things, forced apps to repeatedly print the word “Liberty.” The manager said it was to protest big companies using his work for free.

And in December 2021, malicious code (called “Log4Shell”) was discovered in Log4j – a ubiquitous OSS JavaScript library used in many cloud-based services – that allowed hackers to remotely access and take control affected systems.

These incidents highlight how organizations that depend on OSS for business-critical software, or that contract with outsourced service providers that use OSS, or products or services that contain OSS, rely on the diligence and good faith of the open source community. This has the potential to create supply chain risk for the organization.

How can organizations mitigate these risks?

To mitigate these risks, organizations should consider giving effect to the following:

  • Establish corporate policies and standards for the use of free software, enforceable through a documented and regularly audited process. These policies and standards should include avoiding the use of OSS developed by “rogue” maintainers or switching to other OSS packages if such risks are identified. Google’s Open Source Security Scorecard, which aims to automate OSS scans by referencing the US Open Source Vulnerability Database, is a useful resource.
  • Centrally monitor and maintain a database of open source software used within the organization (and its main suppliers), including the association of free software with individual projects; document the licensing model for each OSS; document OSS updates; and assigning responsibility for consistent monitoring of updates to specific personnel
  • Check for updates before installing. Avoid automatic software updates, instead ensure all updates are thoroughly checked (e.g. by OSS community and security company ratings) before installation
  • Formalize relationships with business-critical OSS maintainers. If possible, consider establishing direct business relationships with maintainers of business-critical OSS, which provide ongoing support and include safeguards against the inclusion of harmful code
  • Incorporate strong open source provisions into contracts with major vendorswhich provide that the organization must consent to the use of any open source software in software (including software-as-a-service products) provided to the organization, and which may also impose obligations on suppliers that give effect to matters raised above.

Comments are closed.