Over the weekend, security pros took to social media to understand and dissect the Log4j vulnerability. Forrester already released a blog on responding to Log4j, but beyond the immediate (and midterm) response issues, there are some longer-term risk management and community considerations — specifically open source support, maintenance, and risk. The fact of the matter is that Log4j’s vulnerability is just the wake-up call we needed.
It Won’t Happen To Us/Happen Again — And Other Lies We Tell Ourselves
This isn’t the first vulnerability discovered in open source software (OSS), but it could be the most consequential, as Log4j is used by millions of servers for both enterprise apps and cloud-based services. What precedent do we have for dealing with a vulnerability found in an open source software that is discovered in a video game? How about the Squirrel vulnerability discovered in October 2021, CVE-2021-41556, that can be exploited to gain access to the underlying machine? And yet, most firms are caught scrambling to respond to Log4j without a strategy or plan for a crisis of this magnitude.
The Myth That Risk Management Of OSS Happens Organically (Or Magically)
So, why aren’t we paying closer attention to the risks associated with OSS? One explanation is that we falsely believe that if so many are using OSS, and anyone can maintain it, that risk management is happening organically — or magically. When everyone is responsible but no one (no single group/team/entity) is accountable, it doesn’t get done. As the security world responds to the Log4j vulnerability and exploits, it’s clear that Log4j is ubiquitous in Java applications, but the library was being maintained by only a handful of unpaid volunteers:
In 2014, in the wake of Heartbleed, the Linux Foundation announced the Core Infrastructure Initiative (CII), a partnership between companies and developers to help fund critical pieces of open source software. In its blog about the initiative, the Linux Foundation noted:
The idea that open source just happens in someone’s basement is a myth. As the software has grown more complex, so has the need for full-time developer support. CII will help identify and fund those projects that are critical to our modern computing fabric but that may be under-resourced.
Over time, the CII transitioned to the Open Source Security Foundation (OpenSSF) with a different funding model (based on membership dues and company contributions rather than grants), but the overall mission was similar: improve open source security and “focus resources on the most mission-critical software.” In October, the OpenSSF raised $10 million in new investments to expand and fund its Open Source Security Foundation project that would identify and fix cybersecurity vulnerabilities in open-source software — but, as they say, a day late and a dollar short.
Open Source Is A Third-Party Risk
In the coming weeks, there will be a lot of second-guessing about the circumstances surrounding Log4j. The single most important question firms will ask of their security teams is this: With all the actions post-Heartbleed, why didn’t we see Log4j for what it was — a third-party software that supports critical infrastructure — and manage the risk accordingly? More details are sure to emerge in the coming weeks, but from what we know now, one thing is clear: Risk management of OSS has NOT kept pace with the OSS usage boom among public and private sectors. And without a risk management strategy, firms don’t have the budget or resources they need and, in hindsight, should have had.
Open source doesn’t fit the classic definition of a third party, but make no mistake: Firms must treat it as a third-party risk to their organization. In fact, the Federal Financial Institutions Examination Council (FFIEC) issued guidance on Risk Management for the Use of Free and Open Source Software in 2004 — a time when OSS was trusted by developers but less so by corporations. Despite the 650% increase in attacks on the software supply chain and ubiquity of open source making up at least 70% of all software, it does not appear that there has been an update to the FFIEC guidance in 16 years.
We Are Late To The SBOM Game
Finally, we’d like to bring up something we’ve talked a lot about: the software bill of materials (SBOM). In the hours after the Log4j exploit was discovered, many security leaders correctly pointed out that a set of accurate SBOMs would help organizations target their responses to the vulnerable components in their environments (“accurate” is the operative word here). However, SBOM could serve a broader purpose. When taken collectively, a search of all public SBOMs in a unified, readable format gives us an idea of which components are ubiquitous and therefore “critical.” If a high percentage of SBOMs from Java applications highlighted Log4j, shouldn’t that tell us that it deserves attention?
In fairness, we’ve known for years that Log4j is ubiquitous, but perhaps its very ubiquity has caused it to slide under the radar. Would a methodical, metrics-based analysis of the most common software packages to appear in products force us to confront the reality of open source that is “too widespread to fail?” The question deserves further discussion, and as the Cybersecurity & Infrastructure Security Agency kicks off its SBOM-a-rama this week (great timing!), we hope that the attendees will consider it.
Protecting Yourself Will Lead To Protecting The Industry
Software has bugs — sometimes severe security bugs, with significant potential consequences. As we think about where to go from here, there are actions that will help protect your organization and actions that will help protect the broader industry. Internally, it’s about recognizing and managing the risk of open source and using all the necessary tools and processes (software composition analysis, third-party risk management, SBOM, asset management) to get your arms around that risk. Externally, think about how your organization can and should be contributing to the open source that you use. Whether it’s through development or funding, every organization can be an active supporter of open source, and that support will help improve open source security. Make open source support part of your risk management strategy.