Open Source a Persistent Risk, Log4j Vulnerabilities Will Linger 

Free and open source software (FOSS) will continue to present a risk to organizations as hackers focus on exploiting security flaws in the code, a report from Moody’s Investors Service found.

In the case of the open source Log4j vulnerability, for example, three to five years could elapse before organizations are finished patching security flaws, and with recent estimates indicating open source makes up 80% to 90% of the average piece of software, the persistent security threats FOSS inherently presents to organizations large and small is significant. 

AWS Builder Community Hub

Log4j Lingers On

Brendan Creane, head of engineering at Tigera, a provider of security and observability for containers, Kubernetes and cloud, noted that flaws in both open and closed source software are growing.

He pointed out that significant time is needed to address the Log4j vulnerability due to the widespread adoption of the logging library and the complexity involved for companies to maintain their third-party libraries.

“Companies are able to determine if their own code is affected, but the effort to determine if any third-party software they use is also affected can be challenging,” he said. “Even then, getting the third-party vendor to update their software will take a significant amount of time due to various issues such as lack of support, new versions containing breaking changes or if the project is no longer maintained.”

This, in turn, requires the company to look into other alternatives or to maintain the library themselves, which takes even more time.

Mike Parkin, engineer at Vulcan Cyber, a provider of SaaS for enterprise cyber risk remediation, added that open source projects have a good track record of developing code that is at least as secure as closed source code, if not more so, and reacting quickly when vulnerabilities are discovered.

“There is always risk, as Log4j showed us, but the risk is often mitigated through transparency of the code and the speed with which flaws can be fixed,” he said. “There are several challenges with Log4j mostly stemming from how widely used it was.”

Parkin noted that finding all of the other applications that depend on it will take time and resources that may not be available, and while the patches are available, finding and fixing all the dependencies will take a lot of effort.

“Views on open source code swing back and forth depending on many factors, and they continue to do so,” he said. “Historically, open source software has offered better security and more transparency, but a major vulnerability like Log4j can tarnish that reputation.”

Owning a Piece of the Puzzle

From Creane’s perspective, adopting a zero-trust security posture dramatically reduces the risk associated with security flaws in both open and closed source software.

“Enterprise customers are now aggressively tracking the trust chain for all open source projects included in SaaS software,” he added. “They need to know that products that use open source components are up-to-date and secure, and they’re insisting software vendors own this piece of the security puzzle.”

Parkin pointed out the threat landscape is constantly evolving as threat actors find new vulnerabilities and expose ones that may have gone unnoticed for years.

“That’s always been the case and it won’t change,” he said. “The nature of open source code is a two-edged blade, in which attackers also have visibility into the code and can find flaws they can exploit, while users and maintainers have visibility into the code and can find flaws they can fix.” 

In January, the White House convened government and private sector stakeholders to discuss initiatives on ways to improve the security of open source software and ways new collaboration could drive improvements.  

The discussion focused on three topics: Preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them and shortening the response time for distributing and implementing fixes. It remains to be seen if that summit will reap the benefits needed to address open source security and supply chain issues.


Nathan Eddy

Nathan Eddy is a Berlin-based filmmaker and freelance journalist specializing in enterprise IT and security issues, health care IT and architecture.

nathan-eddy has 217 posts and counting.See all posts by nathan-eddy