On 9 December 2021 a remote code execution flaw in Apache Log4j 2 (CVE-2021-44228, CVSS 10.0) was disclosed. Organisations that had standardised on one logging library across hundreds of services found the following week expensive in a specific way. What failed, which design decision made it possible, and what is the general lesson about standards?

The trigger

A widely used logging library supported variable substitution in log messages, including a JNDI lookup that could fetch and execute remote code. Because logging is ubiquitous and log messages routinely contain attacker-controlled input — a user agent, a username, a search term — the attack surface was every service that logged anything a user could influence.

Why it propagated

Not by a mechanism inside any one system. By the property that made the standard valuable in the first place: a single library, at similar versions, in hundreds of services, is an estate where one change can be rolled out everywhere and also where one flaw applies everywhere.

Two further amplifiers made the week expensive:

• Transitive inclusion. Many teams did not know they had it. The library arrived through frameworks and vendor agents, so "do we use Log4j" was not answerable by asking teams.
• Vendor and appliance exposure. Third-party products bundled it, so remediation depended on suppliers' release schedules rather than on internal engineering.

Why detection lagged

For most organisations the expensive question was not "how do we patch" — the patch existed within days — but "where is it". Without a software bill of materials, answering it meant scanning build artefacts and running filesystems across the estate, which is a project, not a query. Organisations that already maintained a dependency inventory answered in hours and spent their week on remediation; those that did not spent it on discovery, under active exploitation.

The structural fix versus the tempting local fix

The tempting fix is to standardise less, so that no single flaw reaches everything. That trade is usually bad: seven logging libraries mean seven patch paths, seven sets of expertise, and a longer tail on every future incident. Fragmentation does not reduce total exposure, it spreads it and makes it harder to see.

The structural fix is to accept the concentration and buy the capability it requires:

• A dependency inventory that is generated, not maintained — produced by the build, stored centrally, queryable in seconds, covering transitive dependencies.
• A tested mass-upgrade path, so that "bump this library everywhere and open 180 pull requests" is a routine operation rather than an improvisation.
• Runtime mitigations that do not require a release, such as a WAF rule or a configuration flag, to buy time while the upgrade proceeds.
• Supplier terms that name a disclosure and patch window, because the part of the estate you do not build is the part you cannot fix.

The general lesson

A technology standard concentrates both capability and exposure, and organisations budget for the first and not the second. The argument for standardising is sound — fewer things to know, fewer things to operate, one patch path — and the obligation it creates is that the single patch path must actually work under time pressure, which is a thing you can test.

The trade is explicit once it is written down: standardising pays a smaller total operating cost and a smaller tail of expertise, and it buys an obligation to be able to change the thing everywhere at short notice. Organisations with a generated inventory answered the "where is it" question in hours; those without spent 3 to 10 days on discovery alone, with exploitation already underway.

The practical rule: prefer the standard, and for every standard you impose, name the day you would have to change it everywhere and describe how. If that description does not exist, the standard is a bet that nothing will ever be wrong with the thing you standardised on.

Common weak answers

• "This proves you should not standardise." It proves the opposite for most estates: the organisations that recovered quickly were the ones with a uniform, well-inventoried stack.
• "Scan and patch." Correct and incomplete. The scan is the slow part when there is no inventory, and vendor-bundled copies are not fixed by patching your own code.
• Treating it as a Java problem. The same shape has recurred across ecosystems, and the question a reviewer should carry away is not about one library but about how fast this organisation can answer "where is X" and "change X everywhere".