(Note: This is part three of a series about new legal risks associated with poor open source practices. Part one discussed the implications of the SFC vs. Vizio case. Part two discussed the Executive Order on Improving the Nation's Cybersecurity, and its relationship to open source compliance. This part focuses on the FTC actions related to open source governance and security.)

The 2017 Equifax data breach

On September 7, 2017, Equifax announced that it had discovered that its confidential files about over one hundred million Americans had been leaked, including in many cases social security numbers and drivers license numbers. The announcement made headlines worldwide and led to a 31% decrease in Equifax's stock price within a week. As Equifax slowly released information about the breach, they eventually came to blame the breach on a flaw in Apache Struts, an open source framework for web development. It is true that the flaw in Struts was responsible for the initial compromise. What only came out later was that the true issue wasn't the flaw; the flaw in Struts had been fixed for almost six months. Equifax's internal governance procedures never took the publicly released fix and updated their website software, and instead continued to run known-vulnerable software even when they knew that a fix was available.

We know a lot about what happened in the Equifax data breach because of a report from the U.S. General Accounting Office. According to the GAO and other published reports, the breach began in early March of 2017. The Apache Struts team disclosed a vulnerability, assigned ID CVE-2017-5638, as well as an updated version of the Struts software that fixed the issue. The release was widely publicized. The vulnerability was rated with the highest severity rating possible and allowed "complete system takeover" by attackers.

A team within Equifax monitoring publicly disclosed vulnerabilities flagged the update, but none of the people associated with maintaining the Equifax website received the report or made any updates to Equifax's software. Equifax continued to run the affected software for five months, until a separate investigation revealed that almost all of Equifax's internal systems had been compromised.

The scale of the breach was such that it led to a Congressional inquiry and action by the FTC, and CFPB, ultimately resulting in hundreds of millions of dollars in fines and mandatory remediation for those whose information had been leaked.

The Log4J vulnerability and FTC action

In early January of 2022, another severe vulnerability was announced, this time in the open source library Log4J. As with the Struts vulnerability, this flaw could cause a complete breach of security. Worse, Log4J was used much more than Struts and was deployed across the industry and various government agencies.

What was different about the Log4J vulnerability was that the FTC didn't just act after the breach. Within a couple of days, the FTC sent out a press release (emphasis added):

When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms. The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act. It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action. According to the complaint in Equifax, a failure to patch a known vulnerability irreversibly exposed the personal information of 147 million consumers. Equifax agreed to pay $700 million to settle actions by the Federal Trade Commission, the Consumer Financial Protection Bureau, and all fifty states. **The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future. **

The bolded portions from the FTC press release tell the story: Companies that don't patch known vulnerabilities can be sued by Federal regulators. The FTC explicitly called out the $700M Equifax settlement to highlight that security failures can be very costly.

Open source and software security

The story of these two vulnerabilities may lead to a few people wondering about the security of open source software - after all, two of the largest recent vulnerabilities were the result of open source code. However, a study by researchers at the University of Washington, Microsoft, and the Department of Homeland Security found that "open source does not pose any significant barriers to security, but rather reinforces sound security practices." There have been other widespread breaches due to proprietary codebases. Further, open source communities in general are perceived to be leading when it comes to creating and following secure software development practices, such as the SLSA ("Salsa") standard.

From a security perspective, the real difference between proprietary software and open source software is not whether they have bugs, but how transparent the process is when bugs and flaws do occur. When flaws in proprietary software are discovered, it is in the vendor's best interests to hide and minimize the flaws. In contrast, the community-oriented nature of open source focuses the response on getting the bug fixed. For corporate users of open source, failure to patch a flaw is what can cause bad press, not the existence of the flaw itself.

The risk of poor open source practices at the board level

As noted before, part of the evolving landscape of open source risk has to do with poor open source practices , not just compliance. This is especially true of the risk of government actions due to failure to patch identified flaws in open source projects. This risk is entirely separate from any risks associated with open source licenses. But addressing open source vulnerability risk doesn't require anything new. The same tools needed for open source license compliance are also needed to mitigate and respond to risks from your open source supply chain. If you don't scan your source code for open source, then it is impossible to know if (and where) a software flaw creates a vulnerability for your organization. Open source compliance requires that you know the specific version of your software - and so does open source supply chain security.

What is more concerning from a risk perspective is that an FTC action raises this open source supply chain security risk up to the executive or director level. Where open source compliance may be properly dealt with by your open source program office or legal team, an FTC action is a material risk for any large company at the very highest level, especially for public companies that might be subject to shareholder suits.

Update: Make sure you have updated OpenSSL

In the discussion above, we discussed that poor open source practices - including not being aware of vulnerabilities and not patching them - can lead to FTC action against your company, as well as the damage from confidential information loss. Well, the value of being able to identify your open source use was proven again, shortly after this post was written.

On November 1, 2022 the OpenSSL project announced a new high impact advisory and associated blog post describing a vulnerability affecting versions 3.0.0-3.0.6 of OpenSSL.

In case you are wondering, "What's OpenSSL," OpenSSL is the engine that makes secure web and internet connections possible. For example, this website is served as https ://ospo.co/. That "https" part is powered by OpenSSL. While there are other libraries available that have the same function, OpenSSL is overwhelmingly used throughout the industry, with over 90% market share. Your organization almost certainly uses it somewhere, even if it is not being used in a way that makes you vulnerable.

If you do not have the infrastructure to know where you are using OpenSSL - because you almost certainly are using it - the result can be far more damaging than simple non-compliance with licenses.

(This is part three of the series about increasing legal risks associated with poor open source practices. This part discusses the dangers of FTC actions resulting from poor open source practices. Part one is about the SFC v. Vizio case. Part two discusses the implications of the presidential Executive Order on Improving our Nation's Cybersecurity.)