On 9 December 2021, the Apache Software Foundation disclosed CVE-2021-44228 — a remote code execution vulnerability in Log4j, a logging library used by millions of Java applications, with a CVSS score of 10.0. Within hours the vulnerability had a working public exploit and a memorable nickname (Log4Shell). The NCSC, CISA, and every national cyber agency that matters issued urgent advisories. The CISA director called it the most serious vulnerability I have seen in my career. Several of us, privately, called it more than that.

It is now five weeks since disclosure. The headline-grabbing exploits have slowed. The defenders' work has not. And the lesson of the past month, for any honest practitioner, is not really about Log4j. It is about the question that determined which firms had a bad three weeks and which had an existentially bad three weeks.

The question was: where is it running?

The inventory problem

Log4j is not a piece of software a CIO procures. It is a library that gets bundled inside other software, by vendors and integrators and open-source projects, often without the bundling being visible. By the time the disclosure landed, every CISO in the world was facing the same question — which of our systems include a vulnerable version of Log4j — and almost none of them had a clean answer.

A few firms had a serviceable answer because they had invested in software composition analysis tooling and a maintained inventory of their dependencies. Some had partial answers because their application security team had at least scanned the major applications. Most firms had no answer at all. They had to find out by asking every vendor, scanning every system, watching the network for the indicators, and waiting to see what showed up.

The work that followed was unglamorous. Vendors issued statements, sometimes accurate, often vague. Some vendors took weeks to publish a definitive position on whether their products were affected. Some embedded versions of Log4j were found in surprising places — control systems, network appliances, internal tools nobody had touched in years. The full scope is still being mapped.

The lesson is not patch faster

It is tempting to read Log4Shell as a story about patching speed. That misses the point. The firms that did patch fast were still in trouble, because they did not know where to patch. The firms with mature patch management still spent weeks finding all the instances.

The structural lesson is about inventory — knowing what software you actually run, what it is built on, and where it touches the network. The technical term for this is a Software Bill of Materials (SBOM), and the US executive order on cybersecurity from May 2021 was already starting to push SBOMs as a procurement requirement for federal software. Log4Shell will accelerate that.

The work for the next twelve months, for any firm above a certain size, is to be able to answer the inventory question in under four hours, not four weeks. That is achievable, but it requires a sustained investment in software composition analysis, vendor reporting requirements written into contracts, and a maintained internal register of what runs where.

What boards should ask this quarter

Three questions for the audit committee.

What is our current ability to answer the where-is-it-running question for a new critical vulnerability? The answer should be a time and a confidence level. Within 24 hours, with high confidence for our customer-facing applications and medium confidence for internal systems is a real answer. We would have to investigate is also a real answer, just a worse one.

What is our position on requiring SBOMs from our software suppliers? This is going to become standard in procurement over the next two to three years. The firms that build the muscle now will pay less in the next event.

Where did Log4Shell catch us, and what is the after-action? If the answer is nowhere, we were unaffected, the question to follow with is how do we know. Many firms believe they were unaffected because they did not check carefully enough.

The vendor dimension

A meaningful fraction of the past month's pain has fallen not on the firms that wrote the affected code but on the firms that used the products that included it. The vendor response has been mixed. Some firms — including some very large ones — were slow to publish position statements, slow to issue patches, and slow to provide clear remediation guidance to customers. Some communicated brilliantly. The pattern is worth noting for procurement decisions over the next year.

If you are a firm evaluating software vendors in 2022, how did they handle Log4Shell is now a sensible diligence question. The answer is on the public record.

The open-source dimension

The other conversation Log4Shell has triggered is about the funding and maintenance of critical open-source infrastructure. Log4j is maintained by a small number of volunteer developers — at the moment of the disclosure, three people, one of whom was on holiday — and yet it underpins a sizeable fraction of the commercial Java ecosystem.

The economics here are not sustainable, and the past month has made it visible. Expect industry consortia and government funding to start flowing to critical open-source projects over the next two to three years. The German government has already announced funding for a Sovereign Tech Fund. Others will follow. UK boards whose firms depend on open-source software should welcome this rather than view it as someone else's problem.

One sentence

Log4Shell was a vulnerability in a logging library. The discomfort of the past month has been less about that vulnerability and more about discovering, painfully and at scale, how little we knew about what we were actually running. The next event of this shape — and there will be one — will reward the firms that have spent 2022 fixing the inventory question, and punish the firms that have spent it pretending the question is someone else's.

The work starts now. It does not finish in a quarter.