A report published today by Rezilion, a provider of a platform for tracking and analyzing software vulnerabilities, found that despite all the attention the Java zero-day Log4Shell vulnerability attracted, it appears that nearly 60% of the affected software packages remain unpatched.
Rezilion used Google’s Open Source Insights tool to scan open source software packages, including dependencies, and found that out of a total of 17,840 affected Java software packages, only 7,140 have been patched.
In addition, the Rezilion report cited a Log4j vulnerability resource center maintained by Sonatype indicated that 36% of the vulnerable versions of the Log4j Java log management tool that were actively downloaded from Maven Central are still vulnerable to Log4Shell.
Rezilion also made use of dive, an open source tool for exploring Docker container images, to verify what version of Log4j might be present in containers, and Shodan.io, a search engine for discovering internet-connected devices.
Yotam Perkal, director of vulnerability research for Rezelion, said that the results suggested that many organizations that have deployed a Java application have no way of knowing whether it includes the widely used open source Log4j tool for tracking logs within Java application. Many of the instances of that tool are subject to a recently discovered zero-day vulnerability that can be easily used to execute malicious code within a Java application.
The challenge is that many organizations are using Java software components provided to them by a third party, and they assume that software is secure. However, that third party is often not aware of how that software may have been deployed, noted Perkal.
More troubling still, many organizations that deploy software today don’t actively manage anything that might be considered a software supply chain, he added. Software is deployed as needed with little to no regard for provenance, said Perkal.
Even when organizations can track software components, patching Log4j is a challenge. Java files can be nested layers deep into other files. Java applications can also be packaged in ways that make searching for vulnerabilities more difficult.
Naturally, much of the responsibility for discovering instances of vulnerable Java applications falls to DevOps teams. As organizations embrace DevSecOps best practices that revolve around a software bill of materials (SBOM), it becomes easier to track vulnerable software packages. The issue is that most organizations either don’t have an SBOM or fail to update it as applications are upgraded. In the absence of an SBOM, many DevOps teams are still looking for instances of Log4jShell four months after the initial vulnerability was disclosed.
Unfortunately, this latest vulnerability crisis doesn’t appear to be the wake-up call that drives more organizations to implement DevSecOps workflows, said Perkal. While some organizations are proactively patching applications, many others are still waiting on updates from a third party they hope will address the issue. Those updates, however, may not arrive in time to prevent cybercriminals that know about the Log4jShell vulnerability from wreaking havoc.