Who to blame for the log4j vulnerability?

So far, nobody. Not the open source developers, who responded fast and professionally, and not the companies who handled the risk within a day or two.

Eventually, however, we will have to blame (or complain) about those companies who got cracked because they did not remove the vulnerability in time.

Now, why would a company not fix the issue? Because they don’t know they have the problem. And how could this be possible? Because they don’t have a clean inventory of the components they use. Let me illustrate this by an example.

The following graph shows the open source components of a (back then) almost trivial open source application my research group developed. Each black box is an open source component, sometimes larger, sometimes smaller than log4j in size. We programmed the green-bounded component at the top. Everything is else is other people’s open source code. My staff chose the the yellow-bounded open source components to do the rest of the work. The yellow-bounded components, the so-called direct dependencies, use further components, the indirect dependencies. These are the purple-bounded open source components. There are about 140 components, of which we programmed one. This is normal.

Open source component graph of a small project

Can you see the little blue-bounded box? That’s where logging occurs. In our case, it is the slf4j-api component, which hides the specific logging facility used by the application. We can’t even see in this graph whether we use log4j or logback or something else for logging, it is hidden in some configuration parameters.

Modern development includes large numbers of open source components, the vast majority of which is brought in only indirectly. Sometimes, what you are using is not even visible in the code, but hidden in configuration parameters. It is large, it is complex, it takes effort to vet and monitor.

Do companies need to vet and monitor every single component they use? Absolutely! Is it easy? It wasn’t, but tools have come a long way. Companies may prefer to spend resources on developing new functionality rather than taking open source inventory, but they have to. In fact, those who don’t are not operating at the state of the art.

If something goes wrong, it is not the log4j developers who are to blame, but those lagging companies which didn’t have processes in place to fix the problem.

The text of this blog post and the image (component graph) are licensed under CC BY 4.0 International; please attribute to https://dirkriehle.com.

Posted on


  1. […] Who to Blame for the log4j Vulnerability? (Dirk Riehle) / CC BY […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share the Joy

Share on LinkedIn

Share by email

Share on Twitter / X

Share on WhatsApp

Featured Startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured Projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use