Java’s security architecture and the speed of critical patches
As a fundamental component of most enterprise and mission-critical applications, the Java platform has an extremely rigorous and well-structured security strategy. Within the OpenJDK open-source project, there is a team known as the OpenJDK Vulnerability Group (OVG). Despite the project’s open nature, this team operates under a cloak of complete privacy. Membership of the group is carefully controlled, and only engineers with the requisite security background and skills are selected. Since patches are being developed for currently unpatched vulnerabilities (those that would be classified in the open as zero-day), all communication is encrypted. Unlike other groups in the project, this group’s email exchanges are not published.
Based on the OVG’s work, a well-defined schedule delivers source code changes for security patches on the third Tuesday of January, April, July, and October. Most (but not all) of the major OpenJDK binary distribution providers have representatives on the OVG. This ensures that updates to Java runtime distributions are made available to users. As the principal developer of Java, Oracle releases its patches as a Critical Patch Update (CPU) at the same time the source code repository is updated. Once Oracle’s CPU is publicly available, the embargo on other OpenJDK distributions is lifted, and they are free to publish their update. How long this takes depends on the provider; obviously, the longer the delay, the greater the risk that unpatched vulnerabilities will be exploited. For Azul Core, which includes the Zulu builds of OpenJDK, updates have consistently been made available within one hour of the embargo being lifted.
What good Java security hygiene looks like now
To ensure the highest level of security for your JVM-based applications, you should have a well-defined strategy for deploying JDK updates across your estate. It is all too common to hear users say they do not need to patch their machines because they are behind a firewall. A firewall is not impenetrable. The Equifax breach mentioned earlier used an exploit on machines outside the firewall; once those machines were compromised, the attackers could pass through the firewall as if it weren’t there.
