Misgivings about patching the Log4j vulnerabilities fast have cast a shadow on open source software, but we may be forgetting something…

In December last year, disclosure of the Apache Log4j vulnerability shook the industry, with dire warnings from experts about a long road of cybercriminal exploitation ahead.

Amid many lingering questions on everyone’s mind about how the world should contain the fallout and preempt repeat incidents of this nature, the tricky issue and misunderstandings about open source software or code (OSS) such as Log4j comes to the fore.

To set the record straight, one expert—Tim Mackey, Principal Security Strategist, Synopsys Cybersecurity Research Centre—has proffered his take on what can be done to improve the speed of detecting, resolving and improving far-reaching open source bugs…

DigiconAsia: Will this saga end the era of using open source code bases?

Tim Mackey (TM): 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.

What we are seeing with the Log4j response from the Apache Log4j team is exactly what we would expect to see—a team that is taking the software they produce seriously and responding 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 Bug improved development practices of both open and closed source development teams.

DigiconAsia: Should there be a commercial replacement to protect companies from security implications after Log4j?

TM: 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 extraordinary about it, and there are many other ways of logging data than with Log4j.

That means there really is not much of a commercial software market for a replacement. Any attempt to create a commercial replacement will be fraught with challenges.

However, there is a far simpler solution: simply invest time in improving Log4j since it is open source; the source code is readily available; anyone who wants to modify it can do so under the terms of the Log4j license.

Any interested contributors can create a branch of Log4j and implement whatever fixes needed. 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 have been doing.

While it is 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.

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 did not 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.

DigiconAsia: What kind of governance should be put in place, if any, to help identify and mitigate vulnerabilities sooner rather than later?

TM: From a governance perspective, monitoring for changes in the contents of the National Vulnerability Database (NVD) is a good way of staying on top new vulnerabilities disclosures.

The problem is that the NVD updates slower than media coverage, so with major vulnerabilities like Log4Shell, HeartBleed and Dirty Cow, the team discovering the vulnerability may create a branded name for the vulnerability in an effort to broaden awareness of the issue. Creating a governance policy that monitors for media coverage of a cyber event is not a great practice.

So if media coverage as an input to vulnerability management is a bad idea, and the NVD is a little slow to provide all details, what is the best governance policy? Software Composition Analysis (SCA).

• An SCA tool looks at either the source code for an application, or the executable or libraries that define the application, and attempts to determine which open source libraries were used to create that application. The listing of those libraries is known as a Software Bill of Materials (SBOM).
• Assuming the SCA software does its job properly, then a governance policy can be created that maps the NVD data to the SBOM and you know what to patch. Except that there is still that latent NVD data to account for.
• Some of the more advanced SCA tools solve that problem by creating advisories that proactively alert when there is an NVD entry pending but where the details of that NVD entry are augmented by the SCA vendor. Some of the most advanced tools also offer the function of testing or validating which versions of the software are impacted by the vulnerability disclosure.
• While SCA can close the gap between disclosure and identification, it has a fundamental limitation. If the SCA software has not scanned all of your applications, then at best it can only flag new vulnerability disclosures for a subset of your applications.

From a governance policy perspective, it then becomes an IT function to identify all software and a procurement function to ensure that all software, including updates and free downloads, both comes with an SBOM and that the SBOM is validated using SCA software.

Since software is available in both source and binary formats, it is critical that governance teams heading down this path select SCA software that can effectively process software in all forms and formats. Such a governance policy would assist the identification of new vulnerability disclosures and the impact to the business but would leave the topic of effective mitigation to a different policy since mitigation would require application testing.

DigiconAsia: Given that the original developers release and maintain open source code for free, how can they be incentivized to fix perceived problems quickly?

TM: Part of the problem is a sentiment that has consumers or users of open source projects behaving as if they expect the open source project to behave like a commercial software vendor.

Any reasonably popular open source project on GitHub will list feature requests and comments about when certain problems would be resolved. The modern open source movement was founded on the principle that if you did not like the way the code was working, then you were free to modify it and address whatever gaps in functionality that were perceived to exist.

Feature requests in GitHub issues and complaints about serviceability have an implicit expectation that a product manager is on the receiving end of those requests and that they will be added to a roadmap and eventually be released—all for free.

In reality, gaps in functionality and even in perceived bugs represent opportunities not to request free programming services but instead to contribute to the future success of code that is significantly important to the person registering the complaint.

Yes, some people will not know the programming language used by the project, but—to expect other people to prioritize a complaint from an unknown third party over changes that solve problems for active contributors is not realistic. As much as anything, open source functions through the altruism of contributors.

Over recent years, core contributors for popular open source projects have expressed frustration about the profits made by large businesses from the use of their software. The reality is that if that third party is profiting from the efforts of an open source development team, then they should be actively contributing to its continued success. If they do not, then they run not only the risk that the code in question may change in ways they did not expect, but also that when security issues are identified and resolved that they may have delays in applying those fixes.

After all, if a business is not taking the time to engage with teams creating the software that powers their business, then it is likely they do not know where all the software powering their business originates and cannot reliably patch it.