The Pitfalls of Blind Trust: Open Source and the Log4Shell Vulnerability

Organizations often blindly trust open-source software without conducting security reviews. In light of Log4Shell, this practice must be reconsidered. Tim Mackey of Synopsys explores the issues that arise from blind faith and how best to approach open source software security.

The Log4Shell vulnerability had one predictable outcome – business leaders and even governments became increasingly concerned about the safety of “open source.” Most organizations are unaware that much of the software powering their success is not created by commercial vendors but rather by volunteers. Some of the most critical systems use open-source software. 

Why Is Open Source Widely Trusted?

As we have seen with past major incidents like HeartBleed, Dirty Cow and the Equifax experience with Apache Struts, governmental reviews are in progress, and some teams are seeking to replace the “bad open-source component” in this case, log4j, with a “more secure alternative.” But an essential truth is overlooked in these scenarios– open-source is highly trusted.

Open-source software is so highly trusted that it is freely downloaded and used without significant security reviews in some organizations. That is to say, rarely do businesses perform the same security review on software downloaded from the internet that they perform for the software they create. If you doubt this statement, ask yourself who in your organization reviewed docker or libxml or even the open-source database your applications depend on for security issues. Even if such reviews did occur, it is doubtful that each new update is checked. That is a reflection of the trust placed in those open-source efforts.

Although organizations adopt open-source technologies for varied reasons, here are three primary ones: 

1. It is cheaper: Open-source software often comes without a licensing fee. This is attractive partly because the individual adopting the software does not need to deal with budget approvals or procurement reviews used by their employer.
2. It comes with expert backing: The chosen open source technology was likely developed by experts in their field, and downloading the software is much easier than hiring an expert. 
3. It is industry-vetted: The chosen technology often represents a popular solution to a problem. For example, while many options are available for container orchestration, Kubernetes is the most popular—meaning that both peers and competitors trust its implementation.

The Risk of Open Source 

What gets lost in the adoption discussion is that open-source software, like other commercial software, is often made up of multiple components. There is no Linux executable, nor is there a single Kubernetes executable. Each requires a significant number of dependencies. The same holds true for mobile applications, IoT firmware, and even simple business logic functions deployed on AWS Lambda—they all have dependencies required for the application to function correctly. When people talk about a “software supply chain,” it is this list of dependencies they are referring to, and it is this list of dependencies where the most significant risk from open source usage exists.

If an open-source project is popular enough to become a de facto standard, like Kubernetes, then many volunteer developers are working on that code. Some are even employed by companies using Kubernetes to work on Kubernetes expressly. This translates into resiliency for Kubernetes. If one developer quits or retires, the project moves on. For popular projects, the departure of even key team members can be handled with minimum disruption. 

The same cannot be said for smaller projects. There are millions of projects on GitHub for which the number of developers is in the single digits. And GitHub is not the only repository of open source activity. The loss of a single developer for those projects often means losing someone who understands precisely why specific code areas were written the way they are. These are the kinds of projects most commonly found on the list of dependencies for an application, and they often perform fundamental actions like writing log data—as is the case with log4j. 

Since the number of developers varies widely among open source projects, it is not surprising to see variability in how individual projects respond to a security incident. Some, like Kubernetes or the Xen Project, have very well-defined security processes that reflect their prominence. But others treat a security issue as simply another bug to be resolved at an indeterminate point in the future. A well-defined security process also means that when there is a patch, it will be associated with a security disclosure in CVE format. Projects that treat security issues like bugs are far more likely to fix the bug and not issue a disclosure. This variability makes it difficult for businesses to define the risk in their software supply chains and develop reasonable policies to mitigate that risk.

See More: Five Best Tools to Keep Log4j Vulnerability Exploitations At Bay

How Can Open Source Risks Be Managed?

Mitigating the business risk associated with open-source software starts with accepting that the business benefits from open-source software. Much of the business risk stems from the reality that open source software is managed differently than commercial software. Procurement and patch processes are different, so to expect them to be handled similarly is not realistic. 

The de-risking effort needs to start with a comprehensive asset inventory of all software used by the business, regardless of its origin or the procurement process used during acquisition. Armed with that inventory, it then becomes possible to determine which open source components are used by each asset. That is done using what is known as Software Composition Analysis (SCA) tools. Since the software can be both compiled into a binary and available in source form, it is critical that the chosen SCA tool can process both binary and source-based assets with equal capabilities. Since that asset inventory likely has thousands of entries, you will want the SCA tool to proactively alert you to any changes in security risk within your assets without requiring a re-scan of the assets. 

At that point, you can define your run book for how to address the changes in risk of a new security disclosure. After all, it is rather hard to patch something you did not know you had—and you never know when a new piece of software is created with a vulnerable component. The best way forward is to be cautious and not trust open-source solutions without adequate checks and reviews in place.

Would you trust open-source software blindly? Tell us about the checks to would employ on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d love to know what you think!