Open source for lawyers: Challenges of open source use

Open source is widespread because it’s easy to use. But it comes with unique security challenges, and poor open source management can be a costly liability.

Modern software development involves putting together software puzzle pieces from a variety of sources, and open source represents an ever-growing and important part of that puzzle. Lawyers need to be aware of all the potential risks that come with using open source components in a commercial codebase if they are to advise their clients and protect them from those risks. This article is the second in a three-part blog series that discusses the costs, challenges, and real-world implications of open source use from a legal perspective.

Open source security challenges

In the last post, we focused on the cost of open source use and the potential license compliance–related issues. However, open source is software, and all software is susceptible to security vulnerabilities.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Open source is not any more or less secure than any other code, but it does present some unique challenges. Licensees of commercial software typically expect the licensor to remain aware of potential threats to its code and act quickly to inform the customer of issues and remedy those threats. After all, the licensor has a reputation in the market to protect. In sharp contrast, the need to keep alert to threats and vulnerabilities with respect to open source rests squarely on the shoulders of the users of that open source. Users of open source depend on their lawyers for advice on how to proceed in this scenario.

Tracking known vulnerabilities in components

For users of open source, it can be a challenge to stay apprised of what vulnerabilities have been identified and how to remediate those vulnerabilities. On one end of the spectrum is a “keep your ear to the rail” approach. This hit-or-miss method requires monitoring news feeds, LISTSERVs, and perhaps the publicly available National Vulnerability Database (NVD) maintained by the U.S. federal government.

On the other end of the spectrum is a more automated approach. Automated tools can identify, track, and monitor what open source an organization is using, compare that list in near real time to a variety of sources of open source vulnerability data, and send automatic alerts to designated individuals if the tools discover that the open source used by an organization has any vulnerabilities. These alerts can contain actionable information on how to address any identified vulnerabilities, whether temporarily or permanently.

Open source vulnerability disclosure

Vulnerabilities in open source, as in proprietary code, tend to result from flaws in the way the code was written. The challenge occurs when open source vulnerabilities go undetected for years after the flawed code is introduced into an open source project. During that time, a popular open source project may be used and reused and incorporated into a wide range of other projects or deployed widely without the vulnerability being detected, or at least brought to the attention of those deploying or using the affected code.

At some point, typically as a function of direct or even unrelated research, a vulnerability is detected. When this happens, researchers are likely to make their findings publicly known. They may also post a description of how to exploit the vulnerability and how to patch it. Ultimately, this information may find its way into the NVD (although not, as we recently learned, during a government shutdown). Importantly, this information is equally available to those who intend to do good as well as those who intend to do bad.

CVE-2017-5638, the Apache Struts vulnerability

An unfortunate and well-known case of an organization failing to pay proper heed to the potential vulnerabilities in the open source it was using is the infamous case of Equifax from 2017. Equifax used a popular open source web framework called Apache Struts. Lots of organizations use Apache Struts, and there is nothing inherently wrong or risky in doing so. However, when CVE-2017-5638, an exploitable vulnerability, was discovered and disclosed in the version of Apache Struts that Equifax was using, Equifax failed to remediate it, leaving the personal information of millions of customers at risk.

Open source uses poses a unique challenge when it comes to public knowledge of vulnerabilities. Since hackers have access to the same vulnerability information as anyone else (or may have, through their own “research,” identified otherwise unknown vulnerabilities), and since they are aware of which organizations are likely using what open source projects, organizations must put themselves in a position to know immediately when a vulnerability may impact them and to react quickly.

Learn more about the challenges of open source use

Our new white paper, What Lawyers Need to Know About Open Source Licensing and Management, provides more information on the history and risk of open source software, the challenges related to open source use, and the security implications of open source vulnerabilities. It also offers practical advice for helping your organization or clients.