Does the open source ecosystem needs stricter security around contributors?
If you have not yet heard about a critical vulnerability found in XZ Utils, you aren’t paying attention to critical security news. After all, the discovery of a backdoor in a widely used Linux tool was serious enough to provoke comparisons to the infamous SolarWinds hack. Even Linux creator Linus Torvalds himself talked about it at Open Source Summit North America in Seattle. The malicious code made its way into beta versions of some Linux tools, which means it came very close to being widely propagated. That would have been a flat-out disaster for the entire open source Linux ecosystem.
But once developer Andres Freund issued a security advisory, what ethical hacker Marc Rogers described as an “angry mob of nerds” worked indefatigably to quickly and thoroughly remove the malware and greatly limit the overall impact.
The incident does demonstrate the power of the open source community to quickly avert a crisis. But it also opens up some troubling questions about overall security in an ecosystem based on trust. Here’s why: The attack came from what many experts think was a nation-state actor who spent two years building credibility in the open source community and working faithfully on projects before launching an extremely sophisticated attack.
While we’ve seen sabotage through protestware, this sort of undercover espionage is new to the open source community. In fact, Anjana Rajan, the assistant national cyber director at the White House Office of the National Cyber Director, has likened it to an open source insider threat to open source, similar to the sort of an internal corporate hack we see from a disgruntled employee. Even worse, this insider had access to other projects and, in retrospect, those submissions look suspicious.
And that’s a big deal. How does a community built on trust respond effectively to the reality that there are spies in their midst? Because if there is one, there are probably more.
Most maintainers will likely ignore the entire thing, but it’s certainly fair to ask whether the open source ecosystem needs stricter security around who contributes. Should there be some sort of external certification process? And if so, how would you get developers to buy into a (likely) pain-in-the-neck process for work that they often do for free?
What about having an external company do code review and certify software? That sounds both complicated and antithetical to how the open source community operates. (Not to mention it can raise a legal liability for the company.)
And more broadly, it highlights an ongoing flaw of open source — maintainers doing often thankless but important tasks without any credit or compensation. According to the earlier cited Politico article, there are some signs that the attacker focused on XZ because the developer was maintaining the project solo and was overworked. That sounds pretty similar to a disgruntled employee to me.
Change will come slowly, which means that chief information security officers (CISOs) and cybersecurity teams would do well to consider possible security steps on their side of the code.
First, think of the regular security training most corporate employees get on how to watch for insider cyber threats. Is it at all feasible to start training developers in a similar manner for OS insider threats?
Another idea would be to conduct internal source code reviews on open source software before using it. Would that mean hiring more resources to manage open source? Maybe do a quick version-to-version comparison to ensure code cleanliness? At the very least, we must make sure to always stay current with open source updates, particularly in light of the National Vulnerability Database’s ongoing delays in tagging vulnerabilities. It will certainly keep you safer.
Chris Lindsey is a seasoned speaker who has appeared at conferences, webinars, and private events. He draws on expertise from more than 15 years of direct security experience leading and building security programs, and over 35 years of experience leading teams in programming and software, solutions, and security architecture.
Where and Why Threat Intelligence Makes Sense for Your Enterprise Security Strategy
Safeguarding Political Campaigns: Defending Against Mass Phishing Attacks
Elastic named a Leader in The Forrester Wave™: Security Analytics Platforms, Q4 2022
EMA: AI at your fingertips: How Elastic AI Assistant simplifies cybersecurity
Shining a light in the dark: observability and security, a SANS profile
Elastic named a Leader in The Forrester Wave™: Security Analytics Platforms, Q4 2022
The Cloud Threat Landscape: Security learnings from analyzing 500+ cloud environments
Copyright © 2024 Informa PLC Informa UK Limited is a company registered in England and Wales with company number 1072954 whose registered office is 5 Howick Place, London, SW1P 1WG.