<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

FTC warns of legal action for failure to protect against open source vulnerabilities—here’s how you can minimize risk

Donald Fischer
by Donald Fischer
on January 7, 2022

This week, in response to the ongoing fallout from the Log4Shell vulnerability, the United States Federal Trade Commission issued an alert warning organizations of the urgent need to remediate the vulnerability quickly.

The bottom line: if your company doesn’t take proactive steps to prepare for future vulnerabilities like the one at the center of Log4Shell, then you risk not only the direct damage to your business from resulting hacks or data breaches, but also direct enforcement actions by the FTC (which in the case of Equifax resulted in a $700m settlement) and other US federal enforcement agencies.

Key details and consequences from the FTC alert

The alert describes how this relates to FTC’s mission of consumer protection:

“When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms.”

The FTC also issued a direct warning that companies and vendors will be held accountable for their timely response to Log4Shell and similar situations in the future:

“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.” 

In its article about the new FTC alert, TechCrunch noted a warning from Microsoft that risk is still extremely high for unprotected organizations:

“The FTC’s warning shot comes after Microsoft this week warned that the Log4Shell vulnerability remains a “complex and high-risk” situation for companies, adding that “exploitation attempts and testing remained high during the last weeks of December,” with lower-skilled attackers and nation-state actors alike taking advantage of the flaw.”

Even more interesting, it is clear from the alert that the FTC is looking deeper into the structural challenges causing vulnerabilities like Log4Shell:

​​”The Log4j vulnerability is part of a broader set of structural issues. It is one of thousands of unheralded but critically important open-source services that are used across a near-innumerable variety of internet companies. These projects are often created and maintained by volunteers, who don’t always have adequate resources and personnel for incident response and proactive maintenance even as their projects are critical to the internet economy.[1] This overall dynamic is something the FTC will consider as we work to address the root issues that endanger user security.”

We couldn’t agree more with the FTC assessment. Open source is amazing and a critical foundation of the Internet economy. Yet the continued maintenance and health of this important infrastructure relies on the heroic efforts of volunteer maintainers who have historically earned pizza money at best for their efforts.

Sadly, Log4Shell, is now a poster child for what can happen when there is an imbalance between the value created by open source creators and the value shared back with them in return for their efforts.

How can your organization mitigate risk and prepare for future Log4Shell incidents?

Fortunately, when it comes to the Log4Shell vulnerability, there is a fix, which we have outlined in our recommendations here.

“Organizations can either upgrade Log4j, which is recommended by Tidelift, or prevent improper messages from being logged (probably more difficult), or configure Log4j in certain ways to prevent this (may break other capabilities in your logs).”

The only issue is that the fix assumes that you know exactly where in your organization Log4j is in use. 

This is where Tidelift can help. We make it possible for organizations to implement a proactive approach to managing open source across the organization, so with Log4Shell or future vulnerabilities, the risk can quickly be identified and remediated. A key component of our approach is giving visibility into the open source being used, as well as upstream transitive dependencies. With this advanced visibility, whether it be Log4Shell or a future vulnerability, the risk can quickly be identified and remediated. Again, from our recent briefing:

“As soon as we heard about this vulnerability (before it was listed as a CVE), we started reaching out to our customers to inform and advise them on how to remediate the issue. When looking across our customer base to do our outreach on the problem, we found that all of our customers with Java applications were using Log4j and expect that this is generally the case outside of our customer base as well.

One way Tidelift helps in this situation is by making it easy to find all the “nooks and crannies” where Log4j might be used within your software development lifecycle. Using Tidelift’s open source management tools, organizations can generate a software bill of materials (SBOM) which identifies both direct and also transitive dependencies—thus making it easy to map all the packages impacted by the Log4j vulnerability. 

We’ve been in touch with all our customers, helping them identify and remediate this issue. One customer shared the following:

“Our security team is currently assessing the scope of Log4j usage. They were able to use the OSS inventory report as a starting point. We are so fortunate to have a tool like Tidelift that gives us insight into OSS usage across [the org].”

Another way Tidelift helps is that it allows customers to track fixes as they start happening, so organizations can see what is affected in real time. Tidelift also allows the centralized team to notify and issue recommendations and timelines.”

You can learn more about our approach to helping organizations manage their open source software supply chain here.

Fixing the problem upstream: paying the maintainers

While implementing an approach like the one outlined above can help your organization quickly mitigate the most dire impacts of a vulnerability like Log4Shell, Tidelift also helps your organization proactively prevent vulnerabilities from happening in the first place.

How?

Tidelift pays the maintainers of the exact open source components your organization is using to ensure those components meet enterprise standards, now and into the future. Over time, as more and more maintainers are getting paid for work they’ve historically done on a volunteer basis, we can make open source work better for everyone.

Learn more about our approach to partnering with open source maintainers to improve the health and security of your organization’s open source software supply chain.

Additional resources

Need more information about how to mitigate the impact of the Log4Shell vulnerability? Here are a bunch of resources to help:

New call-to-action