Log4Shell (CVE-2021-44228) was disclosed in December 2021. The remediation effort extended through the first quarter of 2022. The incident produced a blueprint for how organisations should respond to critical supply chain vulnerabilities.
What made Log4Shell severe
Log4Shell is a remote code execution vulnerability in Log4j 2, a widely used Java logging library. The attack vector: an attacker submits a string to an application that logs user input. The string contains a JNDI lookup that Log4j evaluates when it logs the message. The JNDI lookup connects to an attacker-controlled server and loads an arbitrary Java class. One logged string, full code execution.
The inventory problem
The immediate challenge for most organisations was answering the question: where is Log4j in our environment? The answer required an SBOM (software bill of materials) for all applications and infrastructure. Most organisations did not have one. Finding Log4j required scanning running containers, installed JARs, JARs nested inside WARs and EARs, and dependencies in cloud services. The scan took days in many organisations.
The remediation timeline
Upgrading Log4j required: identifying all affected instances, testing that the upgraded version did not break application behaviour, deploying the update to production, and verifying the upgrade was successful. For external vendors' software, you were dependent on the vendor's timeline. For applications you controlled, the upgrade itself was often straightforward; the discovery and testing were not.
What organisations changed after Log4Shell
The organisations that experienced Log4Shell remediation hardest invested afterwards in: automatic SBOM generation as part of the build pipeline, dependency vulnerability scanning in CI/CD, and a software asset inventory that could be queried for specific package versions. The preparation for the next Log4Shell is an SBOM and vulnerability management practice, not a faster response capability.