NPM 'protestware' raises questions on open source security
The deliberate sabotage of an NPM package to protest war in Ukraine worsens the already complex threat of software supply chain attacks, open source and security experts said.
Open source security was thrust into the international spotlight following a supply chain attack on a JavaScript package by its own developer this month.
On March 15, malicious changes to node-ipc, a widely used JavaScript library that handles interprocess communication between app components, were distributed among other apps that depend on it, such as the Vue.js command-line tool. The code, created by node-ipc's developer, Brandon Nozaki Miller, and dubbed "peacenotwar" will wipe data on systems located in either Russia or Belarus to protest the war in Ukraine.
This isn't the first time an open source library has been changed by its developer as a means of protest -- in January another developer, Marak Squires, sabotaged his own NPM packages, colors and faker, which printed anti-corporate messages to command-line tools that rely on the packages as dependencies. Other open source developers have deleted their code as a protest, such as when the creator of RubyGems used by Chef removed them from GitHub to protest Chef Software's customer contract with U.S. Immigration and Customs Enforcement.
However, open source experts say, "peacenotwar" crosses a new ethical line, one that has been widely condemned in the community.
"I'm sympathetic to the desire to protest, but this kind of behavior poisons the well for all open source software," said former Chef CTO Adam Jacob, now co-founder and CEO at infrastructure automation startup System Initiative. "It's ill-considered and user-hostile, and can trivially go wrong. Weaponizing open source to inject malware, no matter how well intentioned, is still injecting malware."
Even open source advocates who support the deletion of open source libraries by their creators at will and describe protest sabotage from Squires as annoying, but not malicious, say "peacenotwar" goes too far.
Tobie Langel
"Asserting your rights to your own stuff is like saying, 'I'm done offering free food,'" said Tobie Langel, principal at UnlockOpen, an independent open source strategy consulting firm in Geneva. "This is like leaving the free food around, but you put stuff on it that makes people sick."
While the intended targets are organizations in Russia or Belarus, "peacenotwar" is still viewed as an indiscriminate attack.
"How much of the software you use or rely on was written by someone in Russia or Belarus? Most organizations have no idea, and a software bill of materials or dependencies will not always help you," wrote Matt Barker, CEO and co-founder of Jetstack, a Kubernetes professional services company, in an email sent through a spokesperson this week. "The bottom line is that if this can happen to people in Russia, it can happen to you."
A new Pandora's Box in open source security
Open source software is here to stay -- some 80% to 90% of the world's software is built using open source components, according to various estimates -- and advocates like Langel argue that the rarity of an attack like the one on node-ipc shows that the community has been, for the most part, overwhelmingly benevolent.
"One way of looking at this is, 'This is dangerous, and [open source] is the Wild West," he said. "The other way of looking at this is as an incredible testimony to the interconnection and the trust [of the community], the positive vectors that are making this a much smaller problem than it could be."
Still, the node-ipc attack should prompt new awareness of open source security risks and tradeoffs among enterprise IT organizations that use it, said Kevin Greene, former cyber research and development program manager for the U.S. Department of Homeland Security and current director of security solutions at software test automation company Parasoft.
All software has vulnerabilities, [but] the attack surface has changed, as well as the threat vectors [with node-ipc] -- it's not an attacker or hacker or adversary who is impacting the supply chain; it's a known entity.
Kevin GreeneDirector of security solutions, Parasoft
"Developers, they're pressed for time, they rely on referrals from their friends ... [and] other people recommending things that are cool," Greene said. "All software has vulnerabilities, [but] the attack surface has changed, as well as the threat vectors [with node-ipc] -- it's not an attacker or hacker or adversary who is impacting the supply chain; it's a known entity."
The possible precedent this attack sets is one Greene feels warrants an urgent response from enterprises to shore up DevOps toolchains, beginning with the awareness of this new attack vector.
However, this is where an urgent need for new open source security practices runs up against the current state of the art. Initiatives such as the Open Source Security Foundation, funded by the Cloud Native Computing Foundation last year to develop projects such as Sigstore and other software supply chain attestation mechanisms are a start, but not yet well-established.
"I don't think the technology is there, I don't think the [corporate] policy is there. And I don't think the security awareness is there," Greene said.
Open source security begins with awareness, strategy
Development, open source and security experts disagree on the best way for companies to protect themselves, given the tools currently available against an attack like the one on node-ipc. Some say developers should use only open source libraries that allow them to mirror a copy of the code, so that packages that pull from public package repositories won't affect their environment. Others say pinning an application to a known good version of a library is a better approach. Some suggest the node-ipc attack will prompt new caution among enterprise developers about using languages such as JavaScript, which are made up of many small interdependent libraries, as opposed to Python, which tends to be developed in larger chunks -- while others vehemently contest that assertion.
There's no one tactical line of defense that will be right for everyone, which prompts experts to shift their focus toward wider strategic trends, such the rise of curated enterprise DevOps platforms with guard rails for developers, and increased security awareness among platform teams and SREs.
These are examples of the kind of strategic thinking it will take to improve open source security, Greene said.
"We've seen with SolarWinds that the build environment is just as important as the software," Greene said. "We need to codify our intuition -- there's so many things we know about things that could go wrong and will go wrong, that we never codify into our daily activities. We're not taking what we've learned and applying it in a realistic way."
For Langel, emerging open source security threats should also raise awareness in the industry about deeper problems with open source sustainability as the ecosystem continues its explosive growth, and how those problems make security risks worse.
"If you're extremely upset about the war in Ukraine, you will not go and sabotage your family dinner over it. That doesn't make sense," he said. "Obviously, it's harder to have a family feeling if your family is 30 million developers."
Problems with compensating community developers fairly, companies taking free software from the community and not contributing back, and a lack of clarity about dependencies between projects raise risks for everyone, Langel said.
"Some of the practices in the ecosystem aren't conducive to a super healthy environment, where everyone feels valued and cared for and happy, the qualities and values of a place you would not consider harming," he said. "And there's enough money flowing in tech that there's no excuse for this."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
Tobie Langel
