December 9, 2023 marked the second anniversary of the public disclosure of CVE-2021-44228, better known as Log4Shell. The vulnerability in Apache Log4j—a ubiquitous Java logging library—was the most significant software security event in recent memory. It affected virtually every organization running Java applications, forced emergency patching over the holiday season, and fundamentally changed how the industry thinks about software supply chain security.
Two years later, it's worth asking: are we actually safer?
The Remediation Landscape
The honest answer is: somewhat, but not enough.
The good news: According to data from multiple sources, the vast majority of directly-referenced Log4j dependencies have been updated. Organizations that actively manage their dependencies have largely addressed Log4Shell in their application code.
The bad news: Sonatype reported that as of late 2023, approximately 25% of Log4j downloads from Maven Central were still for vulnerable versions. One in four downloads. Two years after the most publicized vulnerability in recent history.
There are several reasons for this persistence:
Transitive Dependencies
Log4j is often a transitive dependency—included not directly by an application but by one of its dependencies. Fixing transitive Log4j requires updating the direct dependency that pulls it in, which may require significant code changes if the update includes breaking changes.
Some direct dependencies that include Log4j haven't released patched versions, leaving their users unable to resolve the transitive vulnerability without replacing the dependency entirely.
Embedded and Shaded JARs
Java applications commonly "shade" or "relocate" dependencies, embedding them directly within the application's JAR file under different package names. Shaded Log4j instances don't appear in dependency trees and aren't detected by standard dependency scanners. Finding them requires scanning compiled bytecode or file contents.
Legacy and Unmaintained Systems
Many organizations discovered Log4j in systems they barely knew existed—legacy applications, internal tools, vendor appliances, and embedded systems. These systems may be difficult or impossible to update:
- The source code may be unavailable
- The development team may no longer exist
- The system may be in a regulatory freeze that prevents changes
- The vendor may have gone out of business
Build and Test Infrastructure
Log4j also exists in CI/CD pipelines, test environments, and build tools. These systems are often overlooked in remediation efforts because they're not "production," but they represent real attack surface—especially given the value of CI/CD environments to supply chain attackers.
What Log4Shell Changed
Despite incomplete remediation, Log4Shell drove lasting changes in how the industry approaches supply chain security:
SBOM Became a Household Term
Before Log4Shell, SBOMs were a niche concept discussed at security conferences. After Log4Shell, executives and board members were asking "do we have an SBOM?" The vulnerability demonstrated concretely why you need to know what software components are in your environment.
Executive Order 14028, issued in May 2021, had already mandated SBOMs for federal software suppliers. Log4Shell made the abstract requirement tangible.
Transitive Dependencies Got Attention
The industry's focus on direct dependencies wasn't sufficient. Log4Shell showed that a vulnerability buried several layers deep in your dependency tree can be just as dangerous as one in your own code. Tools and practices for managing transitive dependencies improved significantly.
Vulnerability Response Processes Were Tested
Many organizations discovered that their vulnerability response processes couldn't handle Log4Shell's scale. Patching one CVE in one library sounds simple, but when that library appears in hundreds of applications across your organization, with different teams, different release cycles, and different risk profiles, the coordination challenge is enormous.
Organizations that survived the Log4Shell fire drill used the experience to build better processes: faster triage, clearer ownership, automated detection, and pre-planned communication templates.
Open Source Funding Conversations Started
Log4j was maintained primarily by a handful of volunteers. The revelation that a critical component of global infrastructure was maintained as a side project shocked people outside the open-source community (those inside it were less surprised).
This led to increased funding through the OpenSSF, direct corporate sponsorship of critical projects, and programs like Google's Assured Open Source Software. Progress has been made, but the fundamental sustainability challenge remains.
Are We Safer Against the Next Log4Shell?
Partially. Organizations that invested in the following capabilities after Log4Shell are meaningfully better prepared:
Comprehensive SBOM generation that covers transitive dependencies, shaded JARs, and infrastructure components.
Continuous vulnerability monitoring that catches new CVEs in existing dependencies, not just vulnerabilities in newly added packages.
Rapid response capabilities including automated scanning, clear ownership models, and pre-built communication templates.
Relationship visibility understanding which components depend on which others, so the blast radius of a vulnerability is clear immediately.
Organizations that treated Log4Shell as a one-time fire drill and went back to business as usual are not safer. They'll face the same scramble with the next ubiquitous-library vulnerability.
The Long Tail
The uncomfortable truth is that Log4Shell will never be fully remediated. Vulnerable Log4j instances will persist in:
- Abandoned software that nobody maintains
- Embedded systems with 10+ year lifecycles
- Vendor appliances that the vendor has stopped supporting
- Backup and disaster recovery images
- Air-gapped systems that nobody remembers to patch
This long tail means that Log4Shell exploitation will continue for years, primarily in environments with weak security posture. It's becoming the new EternalBlue—a vulnerability that persists indefinitely in the internet's soft underbelly.
How Safeguard.sh Helps
Safeguard.sh provides the continuous, comprehensive supply chain visibility that Log4Shell proved essential. Our platform detects Log4j—and libraries like it—in direct dependencies, transitive dependencies, shaded JARs, container images, and infrastructure components. When the next Log4Shell emerges, Safeguard.sh ensures you can identify every affected instance in your environment within minutes, not days. Our SBOM management tracks your exposure over time, and our remediation workflows coordinate patching across teams and applications so that nothing falls through the cracks.