Your Final To Do, for 2022 (Or is Log4j, Here to Stay)

Not this one again… did we not speak about this at length at the start of the year? Did we not have every tech news outlet filled with this subject for weeks on end? Have we not spent enough time on this? Did we not fix this and plug the leak?

Well, yes, we did, and no, you didn’t.

To be precise, the Log4Shell vulnerability was disclosed already on November 24th, 2021. This security risk dominated the tech news cycle for many weeks and was a recurring subject during many security conferences in 2022. And yes, the specific vulnerability of this popular logging library was fixed in December 2021 in a new and upgraded version. 

And no, in around 50% of the cases, you or your teams did NOT update this library.

Even worse, as recently as last month (November 2022), close to a third of the new downloads of Log4j was people using the version that contains the vulnerability.

So what happened to our good intentions for 2022? Why were there so many blockers? Let’s be honest, if we want to call ourselves craftsmen in our trade, we should not stand for this Log4j situation.

We can easily discern there are both psychological and technical roadblocks. Admittedly, I don’t have formal training in how the human mind works in which case let me venture into the technical side of this analysis.

Let’s assume that every one of us ‘wants’ to fix the issue, but something is preventing us from doing so.

When we look into why people can’t fix this, it is easy to see that there are two options:

1. People are not able to fix things they don’t know about
2. People cannot fix things if they do not have the skills

As any software engineer goes through their education and advances through their career, the second reason seems unlikely. There is an abundance of help available in the form of tutorials, how-to lists, and video support for this process. Google search ‘How to Update Log4j’ returns 4.87 million results in just 0,41 seconds.

Assuming all developers can read, this leaves us only with the first option: people cannot fix what they cannot know.

Once again, we have two options:

1. People are not aware of the Log4Shell vulnerability and that they need to act upon it
2. People are not aware of where in their landscape they have this vulnerability

I would be really tempted to dismiss option A off the bat. If it were not for the fact that a third of new downloads are still of the vulnerable version of Log4j. This means many people are either not aware or are not reading the manual (I know, not unlikely).

As for option B: this is what we often see. In our Sigrid Software Assurance Guiding Platform, we can easily create the Software Bill of Materials (SBOM) for the applications we manage. This gives me a way to easily search where in my entire application landscape I am using a certain library. Do you have 1,300 applications? No worries, we’ve got you covered.

When we talk to new clients out in the market, we find that this basic insight is a critical lacking factor for many software engineering departments. They just do not know. They are willing and capable, but unable as they lack insight into the specifics of their landscape.

Want to get off Santa’s naughty list this year?

Run an SBOM, remove the Log4Shell vulnerability, and get your software future-fit for 2023 and beyond. Using Sigrid®, our software assurance guiding platform, our clients know what open-source software they are using and automatically prioritize the most urgent fixes. Mitigate all your vulnerabilities at scale across your entire application landscape and create tomorrow with future-fit software.