Using open-source code exposes organizations to a tremendous amount of risk, yet this point is treated like a dirty little secret that nobody talks about. So, let’s live on the edge and take a minute to talk about the problem.
Open-source code is an oddity.
Generally, open-source code is often placed in small packets tucked inside massive programs that corporations use to run their most important processes or it is adopted as a whole program and tasked with running some part of a business. Once embedded and everything is functioning properly, the open-source code may be forgotten about. Yet, certain aspects of this code are often unknown to the end users.
Small facts, like who wrote it? Who has access to it? Was it maintained properly? Is it dangerous?
It is easy to understand why the code is used and why companies are willing to use something that has so many unknowns. Open-source software simplifies the development process and decreases the cost of developing new projects by being ready-made.
Insert Code A into Fold B, and “Ta-Da” you have a box, I mean software.
The unfortunate issue is that, for the most part, IT and security teams use the “head in the sand approach” to cybersecurity and simply gloss over the fact that, at some point, a malicious actor may have gotten ahold of the code, or the possibility does not even occur to them.
Or even worse, the programmer is the threat actor.
The Worst-Case Scenario
Unfortunately, today, we have an excellent example in the news of how this is a real-world problem. One that could be as severe as Log4j but is not as well known.
This situation involves a backdoor that was found in XZ Utils, a JavaScript program deployed by billions of websites worldwide. This supply chain attack involved a sophisticated social engineering effort that saw an attacker earning the trust of the project’s maintainer through legitimate code contributions over multiple years until they were made co-maintainer and gained direct control over the project’s releases and added the backdoor, according to a published report.
To gain control, the attacker essentially convinced the developer that he was overworked and could have more time if he gave up maintaining XZ Utils. So, the developer did so, handing the keys to the project over to an adversary.
Finding the Silver Lining
The XZ Utils is not a one-off situation, and adding to the problem is that there is a possibility the takeover was conducted by a nation-state actor, which raises the stakes even higher.
What the XZ story has done is draw attention to the fact that huge amounts of commercial software incorporate code packages possibly created by an open-source developer clacking away at a keyboard in their garage with little knowledge of its security implications.
If one of those coders goes rogue or gets owned, then all kinds of problems will arise. The trickle-down impact could be huge, so it’s better for all of us if the potential security issues within open-source software are discussed, and not swept under the rug.
And Now, Whatever is the Opposite of a Silver Lining
The problem for security teams is that little can be done about this situation. The largest corporations on the planet leverage huge amounts of open-source software, taking advantage of the fact that someone has written specific components of code that perfectly does a small piece of a larger job and at no cost to the company.
The question then arises. Whose responsibility is it to secure all the code supply chain? Even a software bill of materials (SBOM) does not always help as the open-source code can be found far down the supply chain.
While we don’t have all the answers, there are some steps we can take to minimize the threat. For example, we can build out a software supply chain risk framework that will give some visibility into potential security potholes. Threat hunting will identify the behavior of the bad guy using malicious software, and managed detection and response (MDR) solutions also have a role to play.
These can ID the symptoms but not fix the root cause.
For me, the best takeaway from this conversation is that cases like XZ Utils should start a conversation about security issues surrounding open-source software. The fact that the developer was co-opted into giving control to a bad actor should haunt all open-source developers. In the same manner that everyone must be aware of phishing emails, developers must be aware of who they are interacting with and also have security in mind while developing software.
Open-source software is not going away, and the problem is particularly hard to solve, but ignoring the issue is not the answer.
