Protestware On the Rise: Why Developers Are Sabotaging Their Own Code

"If combating attacks and hijackings of legitimate software on open source registries like npm weren't challenging enough, app makers are increasingly experiencing the consequences of software self-sabotage," writes security researcher and reporter Ax Sharma via TechCrunch. "A developer can, on a whim, change their mind and do whatever they want with their open source code that, most of the time anyway, comes 'as is' without any warranty. Or, as seen by a growing trend this year, developers deliberately sabotaging their own software libraries as a means of protest -- turning software into 'protestware.'" One of the many examples Sharma mentions happened during the first week of 2022, when thousands of applications that rely on the heavily used npm projects colors and faker broke and began printing gibberish text on users' screens. "It wasn't a malicious actor hijacking and altering these legitimate libraries," writes Sharma. "It turned out the projects' developer Mark Squires had intentionally corrupted his own work to send a message of protest to big corporations..." An anonymous reader shares an excerpt from his report: Open source developers are discovering new and creative avenues that no longer limit them to implementing new features for their projects, but to actively express their views on larger social matters by modifying their projects for a cause. And, unlike proprietary code that has to function in line with a paying customer's expectations, most open source licenses are quite permissive -- both for the consumer and the developer -- offering their code with licenses that offer no guarantees as to what a developer is not supposed to and will never do with their code, making protestware a gray area for defenders. In fact, as a security researcher at Sonatype, I observed how protestware posed a challenge for us in the early stages and how we would tweak our automated malware detection algorithms to now catch self-sabotages with projects like colors and faker. Traditionally, the system was designed to spot typosquatting malware uploaded to open source repositories, but cases like malicious hijacks or developers modifying their own libraries without warning required a deeper understanding of the intricacies of how protestware works. The theme has also put major open source registries like npm -- owned by GitHub, a Microsoft subsidiary -- at a crossroads when having to deal with these edge cases. Socket's founder Feross Aboukhadijeh told TechCrunch that registries like GitHub are in a difficult position. "On the one hand, they want to support maintainers' right to freedom of expression and the ability to use their platform to support the causes they believe in. But on the other hand, GitHub has a responsibility to npm users to ensure that malicious code isn't served from npm servers. It's sometimes a difficult balancing act," said Aboukhadijeh. A simple solution to ensuring you are getting only vetted versions of a component in your build is to pin your npm dependency versions. That way, even if future versions of a project are sabotaged or hijacked, your build continues to use the "pinned" version as opposed to fetching the latest, tainted one. But this may not always be an effective strategy for all ecosystems, like PyPI, where existing versions of a component can be republished -- as we saw in the case of the hijacking of the ctx PyPI project. "The conversation around 'protestware' is really a conversation about software supply chain security. You can't trust what you can't verify," Dan Lorenc, the co-founder and chief executive at Chainguard, a startup that specializes in software supply chain security, told TechCrunch. Lorenc's advice against preventing protestware is to follow good open source security hygiene and best practices that can help developers develop protestware more easily and early on. "Knowing and understanding your dependencies, conducting regular scans and audits of open source code you are using in your environments are a start." But Lorenc warns the debate about protestware could draw in copycats who would contribute to the problem and detract open source software defenders from focusing on tackling what's truly important -- keeping malicious actors at bay. And with protestware there remain unknown unknowns. What issue is too small -- or too big -- for protestware? While no one can practically dictate what an open source developer can do with their code -- it is a power developers have always possessed, but are now just beginning to harness.

Read more of this story at Slashdot.