The term protestware recently made global news when organizations in Russia and Belarus were attacked by malicious code that wiped their computers’ files. This malware was distributed through the popular open source JavaScript library, node-ipc, and was introduced by its maintainer in retaliation for Russia’s invasion of Ukraine. However, when popular libraries have a critical vulnerability like this one, the damage multiplies rapidly and can impact any organizations that uses the dependency.
Organizations are not exempt from protestware. There are plenty of reasons for digital activists to protest anything from customer service to discrimination or political views. As such, organizations must act now and add protestware to the list of potential cybersecurity concerns.
Software supply chain attacks and protestware
Protestware can multiply quickly with the exact mechanisms used for supply chain attacks. Until now, the most newsworthy cases have been centered around actions by open source maintainers with direct access to modify open source code, like the case of the node-ipc library that wipes files in Russia and Belarus and the corruption of faker.js and color.js, the popular JavaScript libraries that have thousands of applications depending on them. Notably, this last case was a protest by the maintainer for his work Fortune 500 companies were using for free and without contributing back. Since both libraries are popular and used by many other applications, it effectively became a supply chain attack.
If the goal is to protest digitally through open source software, the obvious expectation is that not just open source maintainers and committers will be protesting. Others will be looking for software supply chain mechanisms such as dependency confusion and typosquatting to add their protestware.
Protestware prevention follows similar recommendations known in open source security, from dependency management to security scans via software composition analysis tools. Let’s not forget that proprietary software is built largely with open source software so that protestware can get into all software.
How to prevent protestware in organizations?
The best way to prevent protestware is to be a good corporate citizen, and while that can’t prevent other attacks, here are some recommendations for organizations to reduce their risk while still successfully continuing to open source software.
1. Dependency scanning and software composition analysis tools
Ensure your organization has software to identify vulnerabilities in dependency open source libraries. By identifying all open source dependencies, sometimes at multiple levels down the chain of open source reusability, development and DevOps teams in organizations can identify vulnerable versions and apply the fixed version of the library. Software composition analysis tools go beyond dependency scanning and provide reporting and policy enforcement functionality. These tools identify risks from known vulnerabilities, including malware used for protestware and software supply chain attacks. The goal is to prevent dependencies with vulnerabilities and avoid protestware making it through the software build process.
2. Private package repositories
Many organizations have added an extra layer to their software development life cycle. This layer comes from the idea of having “trusted” libraries or packages that have been tested and scanned for security risks. An old concept in software development uses what was previously known as whitelisting components. Now known as approved or trusted components, it acts as a single source of truth for all software components. Nexus and Artifactory are examples of package repositories that integrate with package managers and CI/CD tooling to make it part of the process.
In conjunction with dependency scanners and software composition analysis tools, it creates an extra layer of protection against software supply chain attacks and protestware. The challenge with private package repositories is to keep them up to date with hundreds and thousands of required libraries.
3. Secure your CI/CD pipelines
Beyond combining the previous two recommendations and automating them as part of CI/CD pipelines, the next step to prevent protestware is to secure CI/CD pipelines. Preventing hacking into the CI/CD pipeline itself will avoid direct access to open source libraries, even private data, and access credentials.
The key is to tighten access to the CI/CD tool, preventing a bad actor or an employee from protesting via the organization’s software. Strong authentication, regular audits, and penetration testing is recommended to secure CI/CD pipelines. Another important preventive measure is to make sure git-based repositories are correctly configured. Misconfigurations have become a popular entry into organizations’ software and IT infrastructure.
4. Keeping up with the latest releases and patches
The ever-changing software and availability of vulnerability fixes have become a constant challenge for organizations. The 2022 State of Open Source Report showed that the number one support challenge for organizations with open source software is keeping up with updates and patches. The cases of node-ipc, faker.js, and color.js got fixed quickly, and the newer versions are clean. It’s critical to apply the latest releases and patches that fix disclosed vulnerabilities, including protestware.
Protestware and software supply chain attacks can be challenging to anticipate and prevent but is a cybersecurity risk that all organizations must plan for. Attentiveness to changes in packages, security scans, and overall security posture can minimize the risk of your organization’s exposure.