Lessons on Reducing Open-source Risk Since Log4j

I share a birthday with the Log4j event. However, unlike this event, I’ve been around for more than one year. On December 9th, 2021, a Tweet exposed a zero-day vulnerability in Log4j, a widely-used piece of open-source software. The announcement made headlines everywhere, and cybersecurity was suddenly put in the spotlight. It was a wake-up call for many because, in an instant, software that had been considered secure was suddenly at tremendous risk. Looking back over the aftermath of the past year, here’s what Log4j has taught us about reducing open-source risk. 

What Log4j Has Revealed About the Risk of Open-source Libraries 

With a CVSS severity level of 10 out of 10, the urgent response to Log4j was warranted. Upon the announcement, we quickly discovered that 58 percent of enterprises were using the vulnerable version of Log4j, and Microsoft shared shortly after the announcement that state-backed hackers around the world had already tried to exploit the Log4j vulnerability. 

How did this crisis come to pass? Consider the supply chain in manufacturing: companies source parts from third parties and then assemble them in their manufacturing (like an automotive manufacturer sourcing tires instead of making tires themselves). Software development has evolved in the same way. Open-source libraries represent those third-party components that are sourced and then assembled. The issue is that those third-party components can be created, and even updated, by anyone. That’s why ensuring they’re secure, just like tires sourced for assembly into the cars we drive, is crucial. 

Recent executive orders and memoranda make it clear that software security, especially the use of open-source libraries, is a priority governments are paying attention to. Open-source libraries, albeit gloriously convenient, can scale vulnerability in ways we are only just beginning to grasp. 

What Can Be Done Today to Reduce Open-source Risk 

By helping companies find and fix the Log4j vulnerability, known specifically as Log4shell, we learned a few things we can share with you about reducing open-source risk. In the words of our CTO and Founder, Chris Wysopal: "Log4j created awareness that you should have as much security testing automation in build processes as possible. It was also a wake-up call to how security technical debt, when left unaddressed, can cause urgent issues to take an enormous amount of time to fix.”  

Let’s take a deeper dive into the actions that can be taken to reduce the risk involved in using open-source libraries. 

Automate Security Testing in Build Processes 

Organizations using Software Composition Analysis (SCA) were able to quickly find and fix the Log4j vulnerability. They could pinpoint what they needed to fix because the reporting revealed where the function was in the source code and in which transitive library it was being called . Those with Dynamic Analysis (DAST) were able to check the vulnerability of their web apps and APIs against real-world attacks at runtime. This helped people know quickly whether apps that were already in production were vulnerable or not, which you can read more about here. Log4j showed us the importance of automating testing in the build process because old legacy processes with baked in dependencies made it harder to quickly respond than automated DevSecOps processes. 

Diligently Burn Down Security Technical Debt 

One federal cabinet department reportedly spent 33,000 hours responding to the Log4j vulnerability at the expense of other mission priorities because they were trying to protect the department’s networks. Trying to fix one thing can lead to a ripple effect of systems and networks breaking because of the security technical debt. Automating testing can prevent new security debt, but there is still the matter of all the old stuff that must be burned down. When it comes to tackling security debt, one VP of QE Practice writes that, “[Veracode SCA] helps reduce security debt... We have predominantly used it for shift-left, testing code much earlier from a security standpoint. Compared to when we started versus now, we have done a phenomenal job. Year on year, our security debt has been continuously decreasing by 10 to 12 percent.” 

Avoid Approaching Supply Chain Security with a “Set it and Forget it” Mentality 

Risk from open source can be reduced by updating open-source libraries used in software. Veracode’s State of Software Security v11: Open Source Edition found that 92 percent of open-source libraries can be fixed with an update but that 80 percent of libraries used in software are never updated after being added. Chris Eng, Chief Research Officer at Veracode, explains, “The vast majority of today’s applications use open-source code. The security of a library can change quickly, so keeping a current inventory of what’s in your application is crucial. We found that once developers pick a library, they rarely update it. With vendors facing increasing scrutiny around the security of their supply chain, there is simply no way to justify a ‘set it and forget it’ mentality. It’s vital that developers keep those components up-to-date and respond quickly to new vulnerabilities as they’re discovered.” For additional information on securing the software supply chain, check out this blog. 

When it comes to reducing the risk of Log4j specifically, update to a safe version of Log4j, one that is not vulnerable to Log4shell or other vulnerabilities within Log4j. Last month, Chris Wysopal disclosed in a Tweet: “Here is a Veracode customer data snapshot of what Log4j versions are being used. About 6% of apps are using a version vulnerable to Log4shell. 37% are using 1.x versions (not vulnerable to log4shell but containing many other vulnerabilities).” 

Stay Informed About the Security of Open Source 

The constantly evolving world of cloud-native software development is being looked at deeply by some of the best minds in the industry. Watch Forrester Analyst, Janet Worthington, along with Veracode’s Christy Smith and Robert Rhame in this special webinar on The Fragility of Open Source.