A string of “sabotage” incidents in open source software is reigniting discussions of how to safeguard projects that underpin digital platforms and networks around the world. Many of the recent incidents have been dubbed “protestware” because they relate to open source developers making code changes to express support for Ukraine amidst Russia’s invasion and ongoing attack of the country.
In some cases, open source software has been modified to display anti-war overlays or other messages of solidarity with Ukraine. In at least one instance, though, a popular software package was modified to deploy a malicious data wiper on Russian and Belarusian computers. This wave of protests in open source comes just a couple of months after a seemingly unrelated incident in which a maintainer sabotaged two of his widely used open source projects out of apparent frustration stemming from feeling overworked and under-compensated.
The incidents have been relatively contained so far, but they threaten to further shake confidence in the ecosystem just as the tech industry scrambles to address other software supply chain security issues tied to open source. And while financial support, promises of automated tools, and White House attention are welcomed, the open source community is left in need of more robust, sustained help.
In a statement on Thursday, the Open Source Initiative, which has categorically denounced Russia’s war in Ukraine, came out against destructive protestware, imploring community members to find creative, alternative ways to use their positions as maintainers to oppose the war.
“The downsides of vandalizing open source projects far outweigh any possible benefit, and the blowback will ultimately damage the projects and contributors responsible,” the group wrote. “By extension, all of open source is harmed. Use your power, yes—but use it wisely.”
Open source software is free for anyone to use, so the tools and programs are incorporated into everything from independent projects to mainstream, proprietary consumer software. No one wants to take the time to write and test a component from scratch when they could just plug and play a readymade version. This means, though, that all sorts of software rely on projects that are maintained by one or a handful of volunteers—or projects that are no longer maintained at all.
A long-touted benefit of open source software is that it has the potential to be just as secure as, or more secure than, proprietary code, because it’s open to independent vetting. The idea is that many eyes make for few bugs. In practice, though, this safeguard has limitations precisely because there often aren’t a lot of eyes available. The question of sabotage, though, strikes at the heart of open source’s premise as a decentralized, unfederated space.
“There’s nothing really in place, systemically, to keep incidents of insider sabotage from happening more often,” says Dan Lorenc, an open source software supply chain researcher and founder of the security firm ChainGuard. “Projects build a reputation over time, and people who are often pseudonymous come to trust each other’s digital identities because of the work they’ve done. There’s no global approvers list, and each project has a different culture of how you become an approver,” or a developer who is empowered to approve and publish code changes.
