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.