We see an increasing number of cyberattacks, whether intended as malicious fun, for financial gain or even being politically motivated. It has never been more critical to ensure that all systems are maintained with the maximum level of security available.

One of the original design goals of the Java platform was to be able to move code securely around a network for execution. As a result, many aspects of the way the Java Virtual Machine (JVM) works, like bytecode verification during class loading, are designed with this in mind.

One common technique for improving security is to scan application source code for vulnerabilities (technically referred to as common vulnerabilities and exposures [CVEs]). Another is to create a software bill of materials (SBOM) that lists all libraries used when building an application, along with the version details.

Some of the most dangerous vulnerabilities are referred to as zero day. When a zero day vulnerability is discovered, it can immediately be exploited and expose systems to remote code execution. Hackers can easily take control of machines and steal confidential data. In this case, the vulnerability is made public before a fix for it exists.

One example of this vulnerability that affected the Java environment was the Log4Shell exploit of the Log4j library. Log4j is an extremely popular library for generating and recording logging messages. When the vulnerability was reported, almost all Java users had to identify whether and where they were using Log4j and then update the library with the necessary security patch.

Vulnerabilities in Java’s third-party libraries can be particularly challenging because the infrastructure to address them is far less mature than the organizations and processes that ensure the security of OpenJDK. Table C-1 provides examples of high risk vulnerabilities affecting Java libraries that were recently discovered.

Even with an SBOM for applications, locating all instances of an application containing new vulnerabilities in third-party libraries can be difficult and time-consuming if sophisticated software asset management (SAM) software is not in use.

To simplify this, some commercial distributions of OpenJDK can offer ways to quickly identify machines using specific versions of libraries so the update process can be completed as promptly as possible.

Azul Vulnerability Detection is one such system. Azul Vulnerability Detection uses information already available within the JVM as part of the class loader architecture to track all loaded libraries.
This can even extend to providing details about which parts of a library (classes and methods) are in use versus ones that are part of the application but not in an execution path that has so far been followed. This information can be reported to a centralized cloud service. Because the information being used is already in the JVM, this is implemented without the use of a separately installed management agent, thus eliminating any performance impact of this monitoring.

When zero day vulnerabilities like Log4Shell occur, users can request a real-time picture of exactly which applications running on which machines are using affected versions of Log4j. The system administration team can quickly and efficiently work through the generated list to address the vulnerability and ensure the maximum level of security continues to be provided.