Datadog today published a State of DevSecOps report that finds 90% of Java services running in a production environment are vulnerable to one or more critical or high severity vulnerabilities introduced by a third-party library, versus an average of 47% for alternative programming languages.
Based on an analysis of IT environments being monitored using the Datadog platform, the report also notes 63% of high and critical vulnerabilities in Java applications derive from indirect dependencies that are traced back to third-party libraries that have been indirectly packaged with an application.
The report also notes that Java applications are disproportionately affected by the Known Exploited Vulnerabilities (KEV) catalog of vulnerabilities compiled by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Java applications can be impacted by 55% of these vulnerabilities, compared to 7% for other programming languages.
Just under a quarter of Java services (23%) are vulnerable to remote code execution (RCE), impacting 42% of organizations, according to the report.
It’s not clear to what degree organizations might be willing to abandon Java to improve application security, but there are already millions of Java services running in enterprise IT environments that DevSecOps teams need to secure.
Andrew Krug, team lead for security evangelism at Datadog, said it’s not likely organizations will resolve application security issues overnight. Instead, they should be focusing on continuous improvement over time that relies more on automation to ensure best DevSecOps practices are implemented and maintained. The report notes that 38% of organizations running applications in Amazon Web Services (AWS) were still manually deploying applications using “ClickOps” processes versus relying on a continuous integration/continuous delivery (CI/CD) platform.
The biggest challenge with DevSecOps is that not every vulnerability is always present in every application. The Datadog report, for example, noted that while the average service is vulnerable to 19 vulnerabilities, only 5% of vulnerabilities are being actively exploited.
DevSecOps teams should also assume every vulnerability rating is accurate. Datadog applied the Exploit Prediction Scoring System (EPSS) to rank the criticality of vulnerabilities. After applying an adjusted score, 63% of organizations that had vulnerabilities with a critical CVE severity no longer have any critical vulnerabilities. Just under a third (30%) of organizations saw their number of critical vulnerabilities reduced by half or more.
The report also noted that the smaller a container image is, the fewer vulnerabilities it is likely to have. On average, container images smaller than 100 MB have 4.4 high or critical vulnerabilities, versus 42.2 for images between 250 and 500 MB, and almost 80 for larger images.
In general, DevSecOps teams need to carefully evaluate not just how serious a vulnerability is, but also whether the vulnerability can be reached and is running, whether there is a known exploit and whether the software containing the vulnerability is running in a production environment. That’s critical because in 2023 there were more than 4,000 high and 1,000 critical Common Vulnerabilities and Exposures (CVEs) identified, but not every one of them represents the same level of actual risk to a business.
The Datadog report also noted automated security scanners employed by cybercriminals are more of a nuisance than an actual threat. Out of tens of millions of malicious requests that we identified coming from such scanners, only 0.0065% successfully triggered a vulnerability. It’s more important to have a framework to prioritize better prioritize alerts by monitoring raw web server logs or perimeter web application firewall (WAF) alerts. Failing to triage those alerts ultimately leads to a higher level of fatigue that, when vulnerabilities are missed, leads to higher levels of security nihilism, resulting in IT teams being blamed for breaches that are not really their fault, noted Krug.
It’ll be a while before software supply chains become more secure, but the one thing that is certain is that determining which vulnerabilities require immediate attention is critical to ensure developers still have enough time to build and deploy additional applications.
