As we all are familiar by now, the Apache Log4j vulnerability shook the industry last December, and had create much chaos, which we are still witnessing today. Tim Mackey, Principal Security Strategist with Synopsys Cybersecurity Research Centre answers some tough questions on the aftermath of Log4j and its repercussions:
- Are we seeing the end of the era of open source?
- Should there be a commercial replacement to protect companies from security implications after Log4j?
- What kind of governance should be put in place, if any, to help identify and mitigate vulnerabilities sooner rather than later?
- Should better incentives be introduced to encourage the detection of vulnerabilities in OSS? Are there other incentives apart from financial ones?
<p><strong>Are we seeing the end of the era of open source? Why?</strong></p>
<p>While it might be tempting to view a major vulnerability as an indication of open source somehow being deficient, the reality is far from that. Open source software is not more or less secure than commercial software, and in reality most commercial software either includes or runs on open source technologies. Open source simply means that the software is developed in a manner where the source code is available to anyone who wants it.</p>
<p>What we are seeing with the Log4J response from the Apache Log4J team is exactly what we’d expect to see – a team that is taking the software they produce seriously and being responsive to the needs of their install base. Considering that they are volunteers, such a response is indicative of the pride of ownership we often see within open source communities. In reality, an incident like Log4J is likely to improve open source development as a whole – much in the same way that Heartbleed improved development practices of both open and closed source development teams.</p>
<p><strong>Should there be a commercial replacement to protect companies from security implications after Log4j? Why?</strong></p>
<p>This is a really common thought pattern, but one that misunderstands how software development really works. Every software component has what’s known as an “interface.” That interface might be in the form of an API if it’s a web service, or it might represent the functions that can be called when the component is loaded into an application. What that interface looks like, how it behaves, what types of data it takes and in what format, are all examples of decisions the development team creating the component make as they write the component. Those decisions can also change as new features are implemented or as the code evolves. Log4J has an interface for each of its major versions, and they are not the same.</p>
<p>For a commercial replacement of any component to exist, there must be an available market for it. In the case of Log4J, the component logs message data to a log file. There is nothing sexy about it, and there are many other ways of logging data than just Log4J. That means there really isn’t much of a commercial software market for a replacement. But, let’s assume someone was willing to make that investment to have a commercial replacement for Log4J. In that case, they would need to both re-implement the current Log4J interface and then write what is presumed to be “more secure code.” The concept of open source somehow being less secure than commercial software may have been true decades ago, but that is far from true today, but let’s assume that our fictitious company was able to create a perfect logging utility that faithfully reproduced the Log4J interface. Once they’ve created that replacement, they need to market it and ensure that it doesn’t break any software using Log4J.</p>
<p>This is a fairly tall order, and there is a far simpler solution – that fictitious company could simply invest their time in improving Log4J. Since Log4J is open source, that means not only that the source code is readily available, but also that anyone who wants to modify it can do so under the terms of the Log4J license. So our fictitious company could take Log4J, create a branch of it using a process known as “forking the code,” and implement whatever fixes are missing. They then could submit their changes, and after a suitable review by the Log4J team, those fixes could be included in Log4J. At that point, anyone and everyone who uses Log4J could simply update their Log4J version as they’ve been doing.</p>
<p>This entire process is made possible through an open source concept known as “community engagement.” Under this process, an entity that depends upon Log4J (and you all know who you are now), can review, revise, and improve the code. While it’s often thought that open source is just “free software,” somewhere, someone is investing their time in creating and improving upon each and every open source project. If the users and consumers of each project were to invest their time and energy in reviewing and improving the code they depend upon, then not only would we have more robust implementations, but those implementations would be more sustainable as technology moves along.</p>
<p>After all, many vulnerabilities are simply exploits of how code behaves on modern hardware or with modern paradigms, where that hardware or those paradigms simply didn’t exist when the code was originally written. For a perfect example of such a scenario, look at how the vulnerability known as Dirty Cow came to be.</p>