We monitor many thousands of applications with Contrast Assess (IAST), Contrast SCA, and Contrast Protect (RASP) so we have a unique data set compared to others and, so far, we have some really interesting takeaways. Of course, our data, like any data, is skewed to who and what we measure. This data mostly reflects the state of web applications that they know about being run by enterprises with a security program. 

First — what library do developers choose to log with?

Here’s the data:

• 64% package log4j2

• 26% package log4j1

• 47% package logback

• 20% of applications use a logger built into the JVM or have no proper logging library

Readers with an elementary school education will immediately notice those numbers add up to more than 100%. It was not surprising to us that 30% of applications use more than 1 logging library. This mostly happens because many of your dependencies have their own logging calls, and so they end up transitively causing you to bring in their logging dependency. 

To that end, it’s not surprising in our data to see applications that offer log4j2, log4j1, and logback. Many applications have hundreds of dependencies. A study from York University who tried to measure the state of logging showed that Hadoop packages 6 logging utilities and IntelliJ packages 12. It’s crazy out there in the real world.

(If you’re wondering where slf4j is — slf4j is a wrapper with convenience methods that must be backed by a library that does the actual physical writing to logs — and those “real” loggers are the ones we’re measuring.)

How widespread is the Log4Shell vulnerability?

TL;DR: it’s pretty bad. About 58% of Java applications we monitor package a vulnerable version of Log4j2 in them. Some portion of the 26% of applications that package Log4j1 are also vulnerable if they’re using JMSAppender, which we all believe will be relatively rare. Note my repeated emphasis on the word package.

No matter what angle you tilt your head to read that number, it’s bad — really bad — but it’s not as bad as those numbers suggest.

SCA Tools Are Severely Over-Reporting the Issue

The data hints at the difference between SCA with instrumentation  and SCA through analyzing dependency files or repositories at rest.

There are a few ways in which instrumentation is much more accurate for measuring SCA:

1. Many dependencies are only for testing or transitive and are actually not packaged into the artifact.

2. Many dependencies are actually not used, even if they make it into the artifact.

This is well reflected in our data. As of writing, even though 58% of Java applications package a vulnerable version, only 37% actually use log4j2. This actually tracks with our State of OSS report from earlier this year. Anyway – when you have thousands of applications to chase down and fix, a 36+% reduction to worry about is massive. This data also doesn’t show the discrepancy between how at-rest SCA tools would report on dependencies that never made it into the artifact -- so the real difference could be substantially higher.

As an example, 11% of the applications that we monitor package a vulnerable log4j2 but actually only use logback. Fun! Those apps should still update in case that changes one day.

As we discussed in a previous post, Contrast Protect was stopping this attack before anybody even knew it existed. We still want everyone to update to 2.16.0 where possible. But, in the next few days, we need to be absolutely laser focused on the highest risks, and being able to “prune the tree” with this kind of analysis is awesome.

If you believe we can help (we absolutely can), please connect with us to help you protect your Java applications against exploits (including Log4Shell and many other dozens of vulnerability classes) and how you can get started at no charge today.