Log4Shell, four years on

Four years ago this week, a logging library's feature for looking up values via JNDI turned into remote code execution on a substantial fraction of the internet's Java applications.

The response was enormous. It is worth asking what stuck.

what actually improved#

Software bills of materials went from nothing to standard. SPDX and CycloneDX are real formats with real tooling. Most large vendors produce them. US federal procurement requires them. That is a genuine change and it happened fast by industry standards.

Dependency scanning is now default. GitHub, GitLab, and every major CI platform ship it. Most organizations have some visibility into their transitive dependency tree, which very few had in 2021.

Response times improved measurably. Organizations that took weeks to identify affected systems in 2021 now take hours. That is the single most valuable change, because time-to-inventory is the binding constraint in any of these events.

Funding for critical open source increased. Not enough. More than before. Several foundations and corporate programs exist that did not.

what did not improve#

Alert volume made everything worse. A typical application now generates hundreds of dependency alerts. The overwhelming majority are irrelevant — the vulnerable code path is not reachable, the component is not exposed, the "vulnerability" is a denial of service in a build-time tool.

Teams triage this by ignoring it. That is a rational response to a firehose of noise, and it means the one alert that matters gets ignored with the rest.

VEX — Vulnerability Exploitability eXchange — exists to solve exactly this, by letting a vendor state "we ship this component and we are not affected, here is why." Adoption is thin. Producing accurate VEX statements requires knowing your own code deeply, which is expensive, and there is no market pressure forcing it.

Reachability analysis is still not standard. The question that matters is not "do you include this library" but "does your code call the vulnerable function along a path an attacker can trigger." Tools that answer this exist and are not widely deployed.

Maintainer funding is still broken. Log4j was maintained by a handful of volunteers. Four years later, the number of critical projects with one underfunded maintainer is not meaningfully lower.

what I would actually do#

If your organization did the post-Log4Shell work and now has a dashboard nobody reads:

1. Rank by reachability, not by CVSS. A critical CVE in code you never call is lower priority than a medium in your request path. If your tooling cannot tell you which is which, that is the tooling gap to close.

2. Know what is internet-facing. The inventory question that matters is not "what do we depend on" but "what do we depend on in a service an attacker can reach." That is a much shorter list and it is the one to keep current.

3. Practice the drill. Once a quarter, pick a random dependency and answer: where do we use it, which versions, which services, how fast can we patch. If that takes more than an hour, that is your actual finding.

4. Fund something. Pick the three open source projects your business most depends on and send money or engineering time. This is more effective per dollar than most security spending and almost nobody does it.

the honest assessment#

We got much better at inventory and barely better at prioritization. We can now tell you every vulnerable component in your stack within an hour and we still cannot tell you which three matter.

The next Log4Shell will be found faster and patched faster. It will also arrive in an environment with ten times the alert volume, and the teams that have been trained by four years of noise to ignore alerts will ignore it a little longer than they should.

That is progress with a catch, which is the usual kind.