“90% of Java services have critical or severe security vulnerabilities”… or about the quirks of security reporting – JVM Weekly vol. 172

This time it’s going to be a bit philosophical. As you’ve probably guessed, when choosing topics for each successive edition I wade through a mass of headlines and topics to pick realistically what’s most interesting from my perspective. That’s why when I saw that the The State of DevSecOps report by DataDog (whom I personally respect exceptionally) had a lot of space devoted to Java, I decided I needed to get better acquainted with the post – security is an important thing, so let’s see what they’ve unearthed there. And what greeted me?

And at this point I concluded that I no longer understand the world. Either we have a total apocalypse when it comes to software and software supply chain, or there is something wrong with these numbers. Because you know – since 90% of Java services have REAL security vulnerabilities, given that these days any kid with a ChatGPT can supposedly become a hacker, this should be gone in this majority of businesses, right? That’s why I figured I’d use this situation to clarify things a bit, as it fits perfectly into the wider discussion on threats and vulnerabilities reporting.

Well, but what does The State of DevSecOps really tell us? The report, based on telemetry data collected in bulk by DataDog, summarises (among other things) the number of applications that have dangerous vulnerabilities, based on the catalogue of Known Exploited Vulnerabilities (KEV) maintained by the US Cyber Security and Infrastructure Security Agency (CISA). This catalogue, which is a continuously updated, contains information about vulnerabilities actively used by cybercriminals to compromise systems. Analysis of the data from KEV shows that Java services are over-represented relative to other programming languages, with 55% of Java services affected (I honestly don’t know where the 90% figure in the graph came from – digging into the methodologies, it’s probably results from the Software Composition Analysis mentioned in the methodology, Datadog Application Security Management functionality), compared to only 7% of services built using other technologies.

The State of DevSecOps report delves into why vulnerabilities in Java frequently stem from indirect dependencies. These are third-party libraries that come bundled with the dependencies developers use, even though they’re not directly added by the developers themselves. This issue is part of the broader Software Supply Chain conversation that has gained attention in recent years. Indirect dependencies are the main source of third-party dependency vulnerabilities, complicating the process of identifying and managing potential security risks. In this regard, Java lags behind almost every other compared ecosystem.Although if you read into the report’s methodology, there is a small quibble.

The article highlights the importance of thoroughly analyzing the entire dependency tree, including both direct and indirect dependencies, when checking applications for vulnerabilities. It’s wise advice to be fully aware of the components your project relies on. Additionally, it introduces tools like Scorecard from OpenSSF, which evaluates the health of open source libraries, providing us with a wealth of valuable information.

And this is all good advice, but…

The KEV, which is grounded in the CVSS framework, offers a standardized approach for evaluating the severity of IT security vulnerabilities. This CVSS assigns a numerical score ranging from 0 to 10 to each vulnerability. This score is determined by considering various factors, including the complexity of the exploit, its impact on confidentiality, system integrity, and availability, among others.

The whole focus is therefore on assessing so-called ‘worst case risk’ – the risk in the worst possible scenario. This means that the prioritisation of vulnerabilities in KEV is based on the assumption that if a vulnerability can be used for serious attacks, such as remote code execution or full system takeover, it is treated with the highest priority. Prioritisation therefore takes into account the potential maximum impact that a vulnerability could cause, regardless of the current circumstances or the specifics of the environment that could reduce this risk in a particular case.

This conservative approach to risk assessment is critical to successfully defending against the most disruptive attacks, as it allows organizations to prepare for the worst, even though actual exploitation conditions may be less critical. By focusing on the worst-case scenario, KEV helps identify and prioritize vulnerabilities that have the greatest potential impact on overall security.

Well, here’s the dog (DataDog) buried and a topic that has been bothering me for a long time. Remember December 2021, when the entire IT world was patching the Log4Shell vulnerability that was about to threaten the entire global infrastructure? Back then, researchers were already reporting that 93% of cloud solutions could be vulnerable, and last time the White House mentioned it in its report, citing an example of a dangerous vulnerability from recent years. And while we did indeed avoid a dangerous situation then thanks to collective action, a few spectacular incidents happened along the way. More recently, we also completely accidentally avoided a similarly threatening situation with the xz library – a truly fascinating story.

However, I don’t know about you, but when I hear that 90% of applications have a serious attack vector (although as I wrote, when you look at it better it’s more like 55%, which is still some cosmic number), it reads downright unrealistic. And that’s probably why more and more in the security community (and as I’m not a Security Engineer on the subject, I’ve deliberately bounced these thoughts off the experts with a request for proof reading) people are talking about the problems with CVSS, coming up with alternative metrics like VISS (Vulnerability Impact Scoring System) from Zooma or EPSS (Exploit Prediction Scoring System). Even though the aforementioned Java vulnerabilities are indeed dangerous according to the EPSS, and even though DataDog itself warns of the deceptiveness of the “criticality” of individual threats, it does so only after first scaring everyone with twisted numbers. On top of this, vulnerabilities in the languages and libraries themselves are of a different nature than vulnerabilities in, for example, a network device, as they are much harder to get at, as few interfaces are exposed directly to the internet. And the question is whether it is not worth emphasising more clearly that a vulnerability in a component does not mean a vulnerability in an application – because the function may not be used and/or there is no easy exploitation path.

And to be clear, I’m not writing this to downplay security risk of vulnerabilities (and yes the wider business will be doing just that, even without me adding stones to the garden). What I’m wondering about is whether we’re simply doing ourselves a disservice with such flashy headlines and they just put people to sleep more than they realistically translate into raising awareness of the organisation. The fact is that most of the people to whom the article may reach do not know how to understand the terms used in it, making it easy to pick the wrong targets – such as eliminating Java (well, because it’s dangerous) or investing in even better vulnerability scanners (to detect even more vulnerabilities, in large enterprises they can run into the thousands).

Thanks to my daughter, I am rediscovering the wisdom contained in old fairy tales, and really old ones at that, because we are talking about Aesop here, especially in his The Boy Who Cried Wolf, where the eponymous Boy repeatedly gave false alarms about a wolf attack, and when it really appeared, no one believed him and came to his aid. I think the analogy here is clear.