Can You Afford the Total Cost of Free Java?
Summary
If you’re considering running Java on a free JVM distribution without commercial, support, you have to assess the cost of free Java.
Can You Afford the Total Cost of Free Java?
Summary
If you’re considering running Java on a free JVM distribution without commercial, support, you have to assess the cost of free Java. Part of that calculation is the likelihood of a vulnerability being exploited and the consequences of an exploit.
In this post you will learn:
Regulations like GDPR levy stiff fines for acting improperly after a data breach
Azul is the only Java provider other than Oracle that provides regular security updates that enterprises can apply quickly to avoid attacks
When assessing risk, there are two basic calculations:
How likely is something to happen?
What are the consequences if something does happen?
If you’re considering running Java on a free JVM distribution without commercial, support, you have to answer both of these questions.
How likely is an incident on a free, unsupported JVM?
Java is a 31-year-old language with millions of lines of code. It has safeguards that make it a very safe technology, but there are still 10-12 vulnerabilities each update. Of those, there are occasionally a few high and critical vulnerabilities [Image 1]. Occasionally you must update your systems to prevent them from being exposed to data theft or DOS (denial of service) attacks.
Image 1: Vulnerabilities by JDK version. Darker colors indicate more critical vulnerabilities. Click for a larger image.
If you’re using an older version of Java, it’s even more important that you continue to provide updates. Oracle no longer supports JDK 6 and 7, but they have the same security vulnerabilities as more modern versions.
JDK 6 and 7 still have vulnerabilities, without Oracle support. Click for a larger image.
Should you be concerned about Zero Day vulnerabilities in Java?
Once a zero-day (unknown to the vendor and unpatched) vulnerability is discovered or (for known vulnerabilities) the embargo set by the OpenJDK Vulnerability Group is lifted (typically once per quarter), the details become public. A race begins between organizations with vulnerable applications and bad actors who seek to exploit the vulnerabilities before they are patched.
In 2018 the meantime for bad actors to exploit a vulnerability was 32 days. In 2023, bad actors, often using AI-based tooling, reduced the meantime to just five days. Last year, Cloudflare reported on instance in which a vulnerability was exploited in only 22 minutes.
According to Cloudflare’s 2024 Application Security Report, 6.8% of all daily internet traffic was distributed denial of service (DDoS) traffic in Q1 2024, up from 6% in Q2 2023.
Is time to remediate Java vulnerabilities keeping pace with exploits?
Cloudflare’s report notes, “The speed of exploitation of disclosed CVEs is often quicker than the speed at which humans can create WAF rules or create and deploy patches to mitigate attacks.”
According to the InfoSec Institute, the average time to patch a vulnerability or patch is between 60 and 150 days, and security and IT teams usually take at least 38 days to push out a patch. This leaves the window ajar for cybercriminals to exploit a zero-day.
99.2%
98%
2 out of 5
1 out of 10
of new vulnerabilities of builds of OpenJDK can be exploited without privileges
of new vulnerabilities of builds of OpenJDK can be remotely exploited
attacks using new vulnerabilities in builds of OpenJDK are ranked “low complexity”
new vulnerabilities are considered high or very high risk
What are the consequences of an exploited Java vulnerability?
Let’s start with the cost of violating regulations. As an example, reglating bodies in EMEA are very strict about their regulation. The best known, is the General Data Protection Regulation (GDPR). Under GDPR, enterprises must report data breaches within 72 hours of becoming aware of them, so they have to be prepared with a root cause analysis, patches, and the downstream effects of the data breaches. It’s a short window, and GDPR fines can be stiff, especially if personally identifiable information is involved.
If the average time to remediate is 60 days and GDPR is fining you 1000,000 pounds a day, the consequences get very severe pretty fast.
GDPR frequently requires the public disclosure of data breaches as well. Companies can suffer reputational damage, customer attrition, and lost productivity while your engineers are firefighting instead of producing new product features.
How can you prevent Java vulnerabilities from being exploited?
If you’re using a free Java distribution, you can still report an issue with Java. If it’s a common enough issue, it might get fixed. If it’s rare or if you’re the only company with the problem, it could be a long time or it could never be addressed.
You can use the Patch Set Update (PSU) that Oracle releases every quarter, but it’s the entire Java code and takes time to implement and test. Some changes cause regressions in Java estates, forcing enterprises to roll back updates. The consequences in lost productivity can be severe.
A Critical Set Update (CSU) contains only the security update, and enterprises can implement it must faster and more safely. However, Azul is the only Java provider besides Oracle that provides CSUs.
Learn more about the cost of free Java
Azul Deputy CTO Simon Ritter and Product Marketing Manager Dana Crane discussed the total cost of free Java is a webinar series, The True Cost of Free Java Runtimes. The second webinar is The Real TCO of Free Java. Watch it today and avoid costly mistakes with your Java estate.
The post Can You Afford the Total Cost of Free Java? appeared first on Azul | Better Java Performance, Superior Java Support.
*** This is a Security Bloggers Network syndicated blog from Security Blog Posts – Azul authored by Azul. Read the original post at: https://www.azul.com/blog/can-you-afford-the-total-cost-of-free-java/
About Author
