3 min

Among widely used programming languages, Java appears to be the most susceptible to third-party vulnerabilities. Datadog research shows that DevSecOps adoption is crucial to avoiding the creation of cyber threats.

Datadog draws this conclusion in its annual State of DevSecOps report. Third-party libraries are causing major problems in Java. 90 percent of all Java services are vulnerable this way, which contrasts sharply with services running on another language: 47 percent.

Staafdiagram met talen met kritieke of hoge kwetsbaarheden, waarbij JavaScript het hoogst wordt gerangschikt, gevolgd door Java en .net. De tekst aan de rechterkant benadrukt de grote kwetsbaarheden van derden in Java.
Source: Datadog

Another criterion for measuring vulnerability susceptibility is the Known Exploited Vulnerabilities (KEV) catalogue from the U.S. CISA. Datadog notes that Java services are also much more likely to fall prey to exploits here. 55 percent of all Java services contain vulnerabilities that are actively abused, while only 7 (!) percent of applications built with other programming languages suffer the same fate.

Also read: Sonatype SBOM Manager turns static ‘inventory lists’ into actionable assets

But why?

Furthermore, Java also appears to be extremely vulnerable to specific consequences, such as Remote Code Execution (23 percent of all Java services). 42 percent of all organizations therefore risk attack, according to Datadog. However, the research team manages to explain these unfortunate figures by a number of factors.

Namely, some known vulnerabilities are still so common in Java services that they have a major impact on the aforementioned percentages. Spring4Shell (CVE-2022-22965), Log4Shell (CVE-2021-45046 and CVE-2021-44228) and an RCE in Apache ActiveMQ (CVE-2023-46604) are the three most common dangers.

Tip: Log4Shell in 2023: big impact still reverberates

Third-party libraries commonly introduce such vulnerabilities into Java services. Datadog notes that this occurs through a chain of dependencies, which can make it particularly difficult to recognize a threat. In fact, a service may indirectly depend on a vulnerable library through another library. 63 percent of third-party vulnerabilities in Java services arise in this way. The importance of a Software Bill of Materials that keeps track of what software you use and what it depends on (and what those libraries depend on).


Datadog reports that solutions to these kinds of problems are plentiful. Adoption of best practices within DevSecOps requires Infrastructure-as-Code (IaC), automated cloud deployments, secure app development practices, and the use of short-lived credentials in CI/CD pipelines.

These are mostly not new developments at all. Since the advent of the cloud, IaC has existed as a means of ensuring that all changes in a cloud environment are subject to additional scrutiny (both manual and via scans) and are less prone to misconfigurations than manual practices. Automation simply solves many human errors. However, 38 percent of organizations active on AWS continued to set up cloud workloads manually.

Datadog also cites that credentials must, therefore, be short-lived. If they are not, malicious actors can obtain old credentials and enter a system. If they thereby compromise a production environment, they can cause tremendous damage. That harm can be avoided simply by moving away from credentials with a long lifespan.

Also read: Java 22 available: features for improved performance