Log4Shell: The Dependency You Did Not Know You Had

Six days ago, a flaw in a logging library that almost every Java application uses was published. It scores the maximum on the severity scale, it is trivially exploitable by putting a crafted string into any field that eventually gets logged, and within hours of disclosure the internet was being scanned for it at scale. Since then the week has produced a second advisory against the first fix, a current recommended release that is no longer the one everybody rushed to install, coin miners and early ransomware attempts riding the same entry point, and a public remediation deadline of 24 December for United States federal agencies after the flaw was added to the catalogue of actively exploited vulnerabilities. But for most organisations, this week was not spent patching. It was spent trying to find out where the component was. That is the actual story, and it will outlast the vulnerability.

Why this one behaves differently

The emergencies technology teams are trained for involve a product, a vendor, an advisory and a patch. This is not that. It is a component buried inside other people's products, and it reaches your estate by at least five routes. Software you built, where it is a dependency — usually an indirect one, pulled in by something else. Software you bought, where the fix has to be shipped by the vendor and you can only wait and nag. Appliances and devices, where the component sits in firmware and the vendor may be slow, may charge for a supported version, or may no longer exist. Services you consume, where the provider patches and you cannot verify anything. And the route that catches mid-market organisations hardest: software an integrator built for you and handed over, where nobody on either side now knows what went into it. A patch list is useless against that shape of problem. What you need is an answer to a question.

The four-hour question

Here is the test that separated organisations last week, and it is worth running as an exercise regardless of how this particular incident goes. Somebody names a software component. Start a clock. Within four hours, can you produce every place it runs in your estate — applications, servers, containers, appliances, vendor products and hosted services — with an owner for each and an indication of which are reachable from the internet? Organisations that answered by lunchtime had five things in place. An application inventory with a named owner per application. A dependency manifest generated at build time and stored with the artefact, plus the ability to rebuild. A supplier list mapped to specific products and versions rather than to account managers. A device and appliance register with firmware levels. And a record of what is exposed to the internet, which is the field that turns a list into a triage order. Organisations without them spent four days sending emails, and were still reading replies when the second advisory landed.

What to do this week if you cannot answer

Triage by exposure, not by importance. Internet-facing Java applications first. Then anything that accepts strings from outside and logs them — search boxes, user agent headers, hostnames, file names, message bodies, form fields, device identifiers. Then internal applications. Then appliances, which will take weeks because they depend on vendors. While waiting for fixes, three mitigations are worth more than the rest combined. Upgrade to the current release rather than the first one published, because the initial fix was found insufficient within days. Remove the vulnerable lookup class from the archive where upgrading is not yet possible. And restrict outbound connections from application servers, because the exploit works by making the victim reach out to an attacker-controlled endpoint — an application server that cannot initiate arbitrary outbound connections is substantially harder to exploit even when the vulnerable code is present. Web application firewall rules help, and they are a speed bump rather than a fix; obfuscation of the payload was demonstrated almost immediately. Then assume the worst where it is warranted. Anything internet-facing that ran unpatched through last week should be treated as potentially accessed. Look for outbound callbacks in proxy and domain name resolution logs, unexpected child processes of application servers, new scheduled tasks or service units, and credentials that were resident in memory on those hosts. The exploitation window opened before most organisations knew there was a window.

The letter to your suppliers

Do not ask suppliers whether they are affected. That question invites a no from a support desk with no visibility. Ask six things. Which of your products in our estate include this library, and in which versions? What is the fixed version, and when will it be available to us? What interim mitigation do you support without voiding our warranty or support entitlement? Does your hosted service use it, and was it patched? Were you exploited before you patched, and will you tell us? And what is the direct advisory location we should monitor ourselves? Record the answers, and record the silences. A supplier that cannot say which of its own products contains a ubiquitous component has told you something durable about how it builds software, and that belongs in your next renewal discussion rather than in this week's incident notes.

Practical Guidance for Software Inventory Assessment

• Run the four-hour drill with a randomly chosen component, twice a year, and time it.
• Generate a component manifest at build time and store it alongside the artefact, including indirect dependencies.
• Require a component list from software suppliers at purchase and at each major release, as a contract term.
• Keep an appliance and device register with firmware versions, owners and end-of-support dates.
• Maintain an authoritative list of what is reachable from the internet, because that field determines triage order.
• Restrict outbound connections from application servers by default; it is the highest-value compensating control available this week.
• Demand handover artefacts from integrators — source, build configuration and dependency list — before final payment.
• Make the question a lookup, not a project, so the next emergency starts with triage instead of discovery.

The Regional Angle

Three exposures are specific to organisations operating from the Gulf, and the first was commissioned eleven days ago. Saudi Arabia's electronic invoicing generation phase began on 4 December, which means a large number of regional businesses have just put into production an integration between their finance system and a government platform — frequently a Java middleware component, written or configured by a local implementation partner, running on a server that talks to the internet. Almost nobody has classified that connector as an internet-facing application, because it was delivered as a compliance project rather than as software. It is now exactly the kind of component this vulnerability targets, it was built in a rush against a statutory deadline, and the partner who built it is currently either fully booked on other clients' invoicing cutovers or unreachable until January. Put every statutory and bank integration commissioned in the last six months at the top of the list, ask the partner in writing which libraries it ships, and do not accept a verbal reassurance from the consultant who wrote it. The second is the estate nobody owns. Regional commercial property — malls, hotels, hospitals, towers, logistics facilities — is full of building management systems, access control, closed-circuit television, lift controllers, digital signage, parking and irrigation systems, and a striking proportion of them run embedded Java. These were procured by fit-out and facilities contractors during construction, commissioned by a subcontractor, and never entered into any technology asset register, because the technology function was not involved in buying them. There is often no maintenance contract, no vendor relationship, no patching route and no record of what is installed. Start by asking facilities management for the commissioning documentation and the list of systems with network connections, then segment aggressively, because for much of that estate segmentation and egress control are the only controls you will ever have. The third is the support chain. Regional entities commonly hold support through a local partner, who holds it through a regional distributor, who holds it with the vendor. Every question about patch availability travels three hops in each direction, which in a week like this one is the difference between acting on Tuesday and acting the following Sunday. Get the vendor's own advisory page for each significant product, subscribe your team to it directly, and treat the partner as the route for entitlement and installation rather than as the source of information. That single change to how you consume security advisories will help in every incident from now on.

The objection worth taking seriously

The strongest objection is that this is inventory evangelism arriving after the fact. Nobody maintains a complete and accurate component inventory of a real estate. A manifest generated in January is wrong by March. For bought software, hosted services and appliances, the component list belongs to the supplier and no amount of internal discipline produces it — you would have been waiting for vendor releases either way. And what actually reduced risk last week was scanning, blocking outbound traffic and upgrading fast, none of which required a document. That is a fair description of how the week went, and anyone claiming a software bill of materials would have made this painless is selling something. The claim worth defending is narrower. It is not completeness; it is time-to-answer. Four hours versus four days is the difference between triaging in priority order and guessing, and between telling a customer, a regulator or an insurer what your exposure was and admitting you do not know. The objection also understates how much of the effective response depended on inventory anyway: you cannot restrict egress from application servers you have not enumerated, and you cannot prioritise internet-facing systems without a list of which systems are internet-facing. Those two controls carried most of the load last week, and both are inventory in operational clothing. So do not build a register for its own sake. Build the ability to answer one question quickly, prove it with a drill, and accept that the answer will be eighty per cent complete. Eighty per cent in four hours beats a hundred per cent in April.

Common Questions

Is upgrading the library enough?

Upgrade to the current release rather than the first published fix, which was superseded within days. And remember that most of your exposure sits inside products you did not build, where the vendor has to ship the fix.

Should we assume compromise?

For anything internet-facing that was unpatched through last week, yes — investigate for outbound callbacks and persistence rather than only confirming the patch.

What if a vendor has no fix and no mitigation?

Segment it, restrict its outbound connectivity, remove its internet exposure, and start the conversation about replacement. Record the acceptance of risk with a name against it.

What should we expect over the next twelve months?

Expect further advisories and further releases against this library in the coming weeks; six days have already produced one revision. Expect the exploitation pattern to shift over the holiday period from opportunistic mining to quiet access that is sold on and used for ransomware in the new year, which makes January the month to hunt rather than to relax. Expect regulators and sector supervisors in this region to issue directives with short deadlines, and expect customers, insurers and acquirers to start asking a new question in the first quarter: were you exposed, for how long, and how do you know. And expect component disclosure obligations to move from policy discussion into ordinary procurement terms considerably faster than anyone predicted a fortnight ago.

---

Software Inventory Assessment — we run the four-hour drill against your real estate, build the five artefacts that make the answer a lookup, and put the statutory integrations and unowned building systems back on the map.