Log4Shell and the case for knowing what is in your software

A ubiquitous library, a maximal flaw

On 9 December 2021 the Apache Software Foundation disclosed CVE-2021-44228, quickly nicknamed Log4Shell, a remote code execution vulnerability in the widely used Log4j 2 logging library. The flaw scored a maximum 10.0 on the CVSS severity scale: an attacker could execute arbitrary code on a vulnerable server simply by causing it to log a specially crafted string, exploiting the library's support for JNDI lookups.

Log4j is not a consumer product; it is infrastructure. It sits inside enterprise applications, cloud services and embedded systems from countless vendors, often several layers deep in a dependency chain that application teams themselves could not fully see. Within days CISA had ordered federal civilian agencies to patch or mitigate, and security teams worldwide entered an unplanned holiday-season scramble.

“The hardest question Log4Shell posed was not how to patch it, but whether you were even affected at all.”

The visibility problem

The most striking feature of the Log4Shell response was not the exploit itself but the difficulty organisations had answering a basic question: are we affected at all? Many enterprises did not maintain an inventory precise enough to say which applications, in-house or vendor-supplied, incorporated the affected library, and at what version.

This gap gave fresh momentum to an idea that had circulated for years but rarely been mandated: the software bill of materials, a machine-readable manifest of every component and dependency in a piece of software. The May 2021 US executive order on cybersecurity had already directed agencies to require SBOMs from software vendors; Log4Shell supplied the vivid justification.

From good practice to expectation

SBOM generation has since moved from a niche practice into mainstream tooling, supported by formats such as SPDX and CycloneDX and increasingly required in government procurement. Yet adoption outside regulated sectors remains uneven, and an SBOM alone does not patch a vulnerability; it only shortens the time needed to find where one exists.

• Generate and maintain SBOMs for all production software, including internally built systems.
• Track dependency versions continuously, not only at release time.
• Require SBOMs as a condition of procurement from software vendors.
• Establish a rapid patch-and-verify process before the next zero-day, not during it.

What the Society advises

The Society regards supply chain transparency as a core professional obligation for software engineers, not an optional maturity milestone. Practitioners who assemble applications from third-party components bear responsibility for knowing, and being able to disclose quickly, what those components are.