Securing More Than Just Log4j and Spring Beans Vulnerabilites

By now, you’re probably all aware of the recent Log4j and Spring Framework vulnerabilities.  

As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server.  

The Spring Framework vulnerability – made public on March 29, 2021 – was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.    

Just because your organization isn’t using a vulnerable version of Log4j or Spring doesn’t mean that you aren’t using a Java component or development framework that relies on Log4j or Spring Beans. For example, Apache Struts2, ElasticSearch, Apache Kafka, among others, call on Log4j.  

Our co-founder and CTO, Chris Wysopal explained: 

“There might be applications that you have good visibility into and you find rather quickly, but it is challenging to find all your Java applications. The other challenge is, of course, vendor applications that are written in Java. You know, we saw this with Heartbleed many years ago—which kind of kicked off the whole third-party risk—that a lot of vendor applications were written with the OpenSSL library and you had to wait for your vendor to patch that. And the same thing could happen here. A lot of appliances, a lot of packaged software use Java, so I would expect that people are going to be asking their vendors when they're going to be patched." 

Wysopal’s solution? “Software will not become more secure until open-source software becomes more secure,” he said. You could add SBOMs to open-source libraries, but you really shouldn’t rely on an open-source team to track the vulnerabilities. Your organization needs to have its own tools and processes in place.  

Open-source libraries are being increasingly leveraged as a way to speed up development. In fact, our recent State of Software Security (SOSS) report unveiled that 97 percent of the typical Java application is made up of open-source code. And 77 percent of flaws in third-party libraries remain unfixed after three months. 

That said, our SOSS report also found that there has been a noticeable improvement in time to remediation for third-party flaws. Back in 2017, it would take over three years to get to the 50 percent (half-life) closed point, and now it takes just over a year.  

It’s great to see that many organizations are starting to realize the importance of finding and fixing open-source flaws. But there’s still a long way to go.  

In terms of open-source library developers, we need to be giving them free scanning tools and more recognition to individuals who uncover bugs.  

For organizations, Wysopal suggests putting a process in place for selecting open-source libraries to ensure that the libraries you select are free from vulnerabilities. He also suggests investing in scanning tools like software composition analysis (SCA) to catch open-source flaws in your applications before moving them to production.  

Veracode SCA uncovers third-party flaws introduced directly by a developer or indirectly. Our tool then quickly and effectively addresses open-source risk by accurately highlighting where you have open-source vulnerabilities and if they are in your application’s execution path.   

Once you have an SCA tool in place, you should add a policy regarding what level of risk is deemed “not acceptable” in production and prioritize those fixes. Flaws with lower criticality should still be addressed, but only after highly critical flaws are remediated. 

 Log4j and Spring Framework are not the only vulnerabilities of concern. It’s important to be proactive as opposed to reactive. Learn more about our open-source capabilities by scheduling a demo.