It’s been almost exactly one year since CVE-2021-44228 — better known as Log4Shell — turned the software industry upside down. On December 9, 2021, a critical remote code execution vulnerability in Apache Log4j 2, one of the most ubiquitous Java logging libraries in existence, sent every operations team scrambling. Entire weekends were consumed by frantic dependency scanning, emergency patching, and the uncomfortable realization that most organizations couldn’t even answer the basic question: “Do we use Log4j?”
Now, a year later, it’s worth asking: what actually changed? Did the industry learn its lessons, or was Log4Shell just another crisis that generated momentary urgency before fading into background noise?
The State of Log4j Patching#
Let’s start with the uncomfortable reality: Log4Shell isn’t fully remediated across the industry. According to data from Sonatype’s Maven Central repository statistics, a significant percentage of Log4j downloads are still for vulnerable versions. Some of this is build systems pulling cached artifacts, but some represents genuine continued use of unpatched versions.
The long tail of vulnerability remediation in open-source dependencies is a well-known problem, but Log4Shell made it visceral. Transitive dependencies — where your application doesn’t directly use Log4j but includes a library that includes a library that does — meant that many teams spent days just understanding their exposure. Traditional vulnerability scanners that only check direct dependencies missed deeply nested transitive inclusions.
This experience directly accelerated adoption of Software Bills of Materials (SBOMs). The concept predates Log4Shell, but the crisis created the urgency. The U.S. Executive Order 14028 on cybersecurity, issued in May 2021, already mandated SBOMs for software sold to the federal government. Log4Shell provided the case study for why.
The SBOM Progress Report#
Tools for generating and consuming SBOMs have proliferated over the past year. Syft from Anchore, Trivy from Aqua Security, and the SPDX and CycloneDX standards have all seen significant adoption growth. GitHub’s dependency graph and Dependabot, GitLab’s dependency scanning, and various CI/CD integrations now make it far easier to generate SBOMs as part of your build pipeline.
But generating an SBOM and actually using it for security operations are different things. Many organizations can now produce a JSON file listing their dependencies. Fewer have operationalized that data into workflows that automatically flag when a dependency in their SBOM has a new CVE, correlate that with deployment information to assess blast radius, and prioritize remediation based on actual exposure rather than CVSS scores alone.
The tooling is improving, but the operational maturity gap is real. We’ve solved the “generate the SBOM” problem; the “act on the SBOM effectively” problem remains open.
Supply Chain Security Beyond SBOMs#
Log4Shell also accelerated investment in broader supply chain security initiatives.
Sigstore, which reached general availability in October, provides free code signing for open-source projects. The idea is simple: if you can verify that a package was built from a specific source commit by a specific maintainer, you reduce the risk of tampering. Sigstore’s keyless signing approach, using short-lived certificates tied to OIDC identities, removes the historical barrier of key management that prevented widespread adoption of package signing.
The OpenSSF Scorecard project assigns security health metrics to open-source projects. It checks for things like branch protection, CI/CD pipeline security, dependency update practices, and signed releases. It’s becoming common to see Scorecard badges on GitHub repositories, and some organizations are starting to incorporate Scorecard data into their dependency approval processes.
Google’s SLSA framework (Supply-chain Levels for Software Artifacts) provides a maturity model for supply chain security, from basic source and build provenance to hermetic, reproducible builds. Adoption is still early, but the framework gives organizations a vocabulary and roadmap for improving their supply chain security posture incrementally.
What Hasn’t Changed Enough#
Despite genuine progress, several fundamental problems remain.
Maintainer sustainability is still precarious. Log4j is maintained by a small group of volunteers. The vulnerability response burned out already-stretched maintainers. Initiatives like the Alpha-Omega Project from the OpenSSF are directing funding to critical open-source projects, but the broader problem of funding the infrastructure everyone depends on remains unsolved.
Transitive dependency management is still primitive in most ecosystems. JavaScript’s npm audit flags hundreds of advisories, most of which are in deep transitive dependencies that applications never actually invoke the vulnerable code path of. The noise-to-signal ratio discourages developers from engaging with the results, which is exactly the wrong outcome.
Vulnerability detection timing hasn’t fundamentally improved. Zero-day vulnerabilities in widely-used libraries still create fire drills. The time from vulnerability disclosure to widespread exploitation continues to shrink, while the time to patch — especially for organizations with complex deployment pipelines — hasn’t meaningfully decreased.
My Take#
One year on, I’d give the industry a B-minus. Genuine progress has been made in tooling, standards, and awareness. SBOMs are becoming a real practice rather than a compliance checkbox. Sigstore and SLSA are building the infrastructure for verifiable supply chains. Organizations that couldn’t answer “do we use Log4j?” in December 2021 can now answer that question for most of their dependencies.
But the structural problems — underfunded maintainers, noisy vulnerability scanning, the economics of open-source security — are harder to solve than the tooling problems. We’ve built better smoke detectors. We haven’t addressed why buildings keep catching fire.
If your organization hasn’t adopted SBOM generation, dependency scanning in CI/CD, and a process for responding to critical dependency vulnerabilities, the anniversary of Log4Shell is a good moment to start. The next Log4Shell is a matter of when, not if. The question is whether you’ll be scrambling again or prepared this time.