Mar 25, 2022 3:35 PM

The Fragile Open Source Ecosystem Isn’t Ready for ‘Protestware’

A recent uptick in disruptions to open source software, including incidents aimed at objecting to Russia's war in Ukraine, have left the community on edge.

Illustration of a person's legs walking into a trip wire made of code

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.

There's no way to completely remove the threat that a maintainer of an open source project will go rogue, either for personal reasons or because of a criminal or government influence. But so-called “insider threats” can't completely be eliminated within private companies either. The open source community and major influences like Github are increasingly looking to automated code scanning tools to put more eyes (if digital ones) on even the most esoteric projects and catch more bugs or potentially suspicious changes before they go live or soon after.

Casting such a wide net is particularly important because of another problem in open source security in which bad actors infiltrate projects or convince burned out maintainers to hand over the reins and then have full control to deploy whatever they want. Automated scanners have limitations, though, and Lorenc notes that they are often better at catching accidental bugs than those that are intentionally designed for sabotage.

Longtime open source security researchers and practitioners are adamant, though, that another vital safeguard exists right out in the open: massively expanding the support and resources maintainers can seek in general and especially if their fun hobby project eventually morphs into a critical link in the global software supply chain.

“It’s easy to take from open source, but giving back is ad hoc or best effort, and most beneficiaries may not even realize they’re beneficiaries and aren’t contributing back in any meaningful way,” says Eric Brewer, Google's vice president of cloud infrastructure.

Brewer likens open source software to public infrastructure like roads or utilities. Underfunding such infrastructure can (and does) lead to mismanagement and security issues. He emphasizes that open source advocates have been raising this alarm for years, but that there has finally been progress on awareness in the wake of major incidents like the SolarWinds supply chain hacking spree perpetrated for Russian espionage and revelations of vulnerabilities in the Log4j open source logging library, which exposed organizations and networks around the world to attack.

In January, the White House held an open source security summit with tech giants including Google, Microsoft, Meta, Amazon, GitHub, and the Apache Software Foundation. Companies like Google have made significant financial commitments in recent months to support supply chain and open source security along with other facets of cybersecurity.

Brewer emphasizes, however, that the efforts will take sustained support beyond just writing a check.

“We have to look at what promises are we assuming from maintainers that they haven’t necessarily committed to,” he says. “And the goal is not to replace the role of maintainers but actually to support and help them, and ask them what kind of help they need. They’re doing a great job already and in some ways the worst things we could do would be to come in and temporarily help fix some problems and then disappear—and that is exactly the easiest thing to do. So there needs to be some consistency in support, something sustainable.”

When it comes to the threat of sabotage, ChainGuard's Lorenc fears that in the short term there may be a spike in copycats after the recent series of high-profile incidents. And he emphasizes that there is no magic-bullet technical solution that can solve the problem for open source security. But he agrees that more financial and moral support for maintainers will create important safeguards around critical projects.

As open source development has gained acceptance and mainstream notoriety, the stakes have become perilously high to secure projects and prevent backlash that could drive governments and other powerful entities away from open source.

“I think the temptation of using open source projects as weapons against Russia should be resisted," software engineering consultant Gerald Benischke wrote in a blog post last week. "It sets a dangerous precedent and may ultimately set back the open source movement and push organization back into seeking refuge in commercial software with all it’s opaqueness and obscurity.”