Spies Among Us: Insider Threats in Open Source Environments

COMMENTARY

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.

So, it could have been worse, right? Yes and no. 

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. 

A New Kind of Espionage

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. 

CISOs Should Consider These Security Steps

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.