A chain of Incidents of “sabotage” in open source software are reigniting discussions about how to protect the projects that underpin digital platforms and networks around the world. Many recent incidents have been dubbed “protestware” because they involve open source developers modifying code to express support for Ukraine amid the Russian invasion and continued attack on 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 case, however, a popular software package was modified to deploy a malicious data eraser to Russian and Belarusian computers. This wave of open source protests comes just 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 the feeling of overwork and underpayment.
The incidents have been relatively contained so far, but they threaten to further undermine confidence in the ecosystem, just as the tech industry scrambles to address other related software supply chain security issues. to open source. And while financial support, promises of automated tools, and attention from the White House are welcome, the open source community needs stronger, sustained help.
In one declaration On Thursday, the Open Source Initiative, which has adamantly denounced Russia’s war in Ukraine, spoke out against destructive protest software, imploring community members to find creative and alternative ways to use their positions of maintainers to oppose the war.
“The disadvantages of vandalizing open source projects far outweigh any possible benefit, and the backfire will ultimately damage responsible projects and contributors,” the group wrote. “By extension, all open source is harmed. Use your power, yes, but use it wisely.
Open source software is free to everyone, so tools and programs are built into everything from independent projects to proprietary mainstream software. Nobody wants to take the time to write and test a component from scratch when they could just plug and play an out-of-the-box version. This means, however, that all kinds of software rely on projects that are maintained by one or a handful of volunteers, or on projects that are no longer maintained at all.
A long-vaunted advantage of open source software is that it has the potential to be just as secure, if not more secure, than proprietary code, because it is open to independent verification. The idea is that many eyes make few insects. In practice, however, this protection has limits precisely because there are often not many eyes available. The issue of sabotage, however, strikes at the heart of the premise of open source as a decentralized, unfederated space.
“There’s nothing really in place, systemically, to prevent incidents of insider sabotage from happening more often,” says Dan Lorenc, open source software supply chain researcher and founder of the security company ChainGuard. “Projects build reputations over time, and often pseudonymous people come to trust each other’s digital identities because of the work they’ve done. There is no global list of approvers, and each project has a different culture of how you become an approver, or a developer who has the authority to approve and release code changes.