In early December 2021, rumors about a remote code execution vulnerability in Log4j began circulating on social media, and it was quickly dubbed Log4Shell. Over the next three days, those rumors were confirmed, an additional vector was found, and the immense scope of the vulnerability became clear. Log4j, a logging library used in Java development since 2001, could be provoked into loading code from an attacker’s host.

The vulnerability was found in on-premises software, software as a service (SaaS), and internally developed applications. Vulnerable versions of Log4j were in organizations’ applications’ direct dependencies and in their transitive dependencies. It was embedded in vendor products, including monitoring, visualization, and security tools. Mitigating this vulnerability required companies to change application configurations in anything Java-based. Remediating it required dependency updates, testing and deployment cycles, and redeployment of vendor software.

In the aftermath of this vulnerability, some organizations responded quickly and with relative efficiency. Others lost days before even beginning their response. In spring of 2022, some organizations were still struggling to fully complete their remediation. There is much we can learn from these differences among organizations, and this paper attempts to capture and synthesize some of those learnings.