One of the dirty secrets of IT is that even when organizations are aware of a critical vulnerability, they are often unable to do much about it. In some cases, they are unaware if they are using a software component that has been discovered to be vulnerable. In other cases, they simply don’t have the expertise required to patch a software component that was provided to them by a third party.
A report published this week by Rezilion, a provider of a platform for tracking and analyzing software vulnerabilities, shines a light on the issue. Despite all the attention a zero-day Log4Shell vulnerability in Java applications, the report finds nearly 60 percent of the software packages that might be affected remain unpatched.
In addition, the Rezilion report notes a Log4j vulnerability resource center maintained by Sonatype made it possible to discover that 36 percent of the versions of the Log4j tool for managing logs within Java applications that were downloaded from a maven central repository are still vulnerable to Log4Shell.
The results suggest many organizations that have deployed a Java application have no way of knowing whether it includes the open-source Log4j tool for tracking logs that is widely employed within Java applications. 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.
Active software management can mitigate challenges
Many organizations are relying on software components provided to them by a third party that they assume keeps software secure. However, that third party is often not aware of how that software may have been deployed, so any effort to patch that software requires a level of collaboration that doesn’t exist.
The simple truth is many organizations that deploy software today don’t actively manage anything that might be considered a software supply chain. Software is deployed as needed with little to no regard for provenance. Even when organizations can track software components, patching Log4j continues to be a challenge. Java files, for example, can be nested layers deep into other files. Java applications can also be packaged in ways that make searching for vulnerabilities extremely challenging.
Patch management opportunity for MSPs
Obviously, there’s a clear opportunity for managed service providers (MSPs) to help organizations patch software components in a timelier manner. The first step is to offer a service through which a software bill of materials (SBOM) can be created that makes it simpler to track vulnerabilities within software packages. Sadly, most organizations either don’t have an SBOM or fail to update it as applications are upgraded. In the absence of an SBOM, organizations will spend months looking for instances of a vulnerability that could be hidden anywhere within a portfolio of applications.
If those applications are not updated it’s only a matter of time before cybercriminals exploit them. In effect, every time a vulnerability is discovered, every organization is in a race against time. MSPs that have patch management expertise are always going to be in a better position than most internal IT teams to win that race.
Photo: selinofoto / Shutterstock
