At the end of 2021, the world was confronted with one of the most significant cyber incidents of the past decade: the Log4j incident. What made this incident so remarkable was that it did not revolve around one organization or supplier, but around a small piece of software that was deeply embedded in countless applications worldwide.
For executives and CISOs, Log4j was a harsh lesson in how invisible and simultaneously critical digital supply chains are. Many organizations only discovered during the crisis that they were using Log4j — often without knowing it themselves.
What is Log4j and why is it used so extensively?
Log4j is a so-called logging library. Logging is a basic function in software: recording events, error messages, and system activities to manage applications and solve problems. Log4j was developed by the Apache Software Foundation, a non-profit organization that develops and manages open-source software.
Because Log4j was free, reliable, and easy to integrate, it became the standard for Java applications for years. Java is a programming language widely used in business software, web applications, and cloud platforms. As a result, Log4j was not only found in custom software, but also in commercial products and cloud services.
What went wrong: the Log4Shell vulnerability
The vulnerability, known as Log4Shell, enabled attackers to remotely execute code on vulnerable systems. In simple terms: by sending a special message, an attacker could gain complete control over a server.
The problem was deeply embedded in Log4j’s functionality and had gone unnoticed for years. When the vulnerability became public, it turned out that millions of systems worldwide were directly vulnerable. This was a so-called zero-day: a vulnerability for which no security update was available at the time of discovery.
Why this incident was so difficult to manage
One of the biggest challenges with Log4j was visibility. Many organizations used Log4j indirectly, through software packages or SaaS services from suppliers. Even IT departments had difficulty quickly determining where exactly Log4j was running.
This led to hectic situations where organizations spent days or weeks inventorying, patching, and monitoring. Executives faced uncertainty: “Are we vulnerable, and if so, where exactly?”
The impact on organizations, including in the Netherlands
The Log4j incident had worldwide impact on governments, hospitals, banks, and companies. In the Netherlands too, supervisors and the National Cyber Security Centre raised alarms. Many organizations had to activate crisis structures, implement additional monitoring, and question suppliers about their dependencies.
It was notable that relatively little direct damage was reported, but this was mainly due to the enormous effort organizations made to prevent abuse. Log4j continued to be actively scanned and attacked for years afterward.
A classic supply chain problem in digital form
Log4j demonstrates that supply chain risks are not only about suppliers and contracts, but also about software building blocks. One vulnerable open-source component had consequences for a large part of the digital world.
For executives, this is an important insight: risks do not only arise with “major” suppliers, but also with small, invisible links deep in the chain. These are often the least transparent.
Executive responsibility and reality
Although Log4j is open-source software, responsibility remained with the organizations that used it. They had to assess risks, implement measures, and be accountable to customers and supervisors.
This raises a difficult question for executives: how do you maintain control over risks that arise outside your direct sphere of influence? The answer does not lie in complete control, but in awareness, insight, and preparation.
What organizations can learn from Log4j
The Log4j incident has sharply highlighted the importance of insight into software dependencies. There is increasing talk of a Software Bill of Materials (SBOM): an overview of all software components in an application. This helps organizations respond more quickly to new vulnerabilities.
Additionally, it is essential to make clear agreements with suppliers about vulnerabilities, updates, and communication during incidents. Not as a paper exercise, but as part of active risk management.
From technical detail to strategic theme
Log4j began as a technical problem, but ended as a strategic risk. It affected continuity, compliance, reputation, and trust. This means this topic clearly belongs at the executive level.
By structurally discussing and anchoring supply chain risks in governance, organizations can better deal with uncertainties in an increasingly complex digital ecosystem.
Conclusion: you only see it when it goes wrong
The Log4j incident made it painfully clear how dependent organizations are on software they do not build themselves and often do not even know. This is precisely what makes digital supply chain risks so treacherous.
For medium-sized organizations, the most important lesson is clear: insight and awareness are not a luxury, but a prerequisite. Those who understand today where their digital dependencies lie will be stronger tomorrow when the next Log4j moment presents itself.
