Five Years After Log4Shell: Why Most Teams Still Can’t Name Their Own Software

It’s hard to believe, but the Log4Shell disclosure hit the headlines on December 9‑10, 2021 – almost five years ago. Back then the world was scrambling: a CVSS score of 10.0, hundreds of millions of devices potentially exposed, and a frantic race to patch. The panic was real, the media loud, and the urgency palpable.

What many forget, however, is that patching itself wasn’t the real bottleneck. The true nightmare was figuring out where to apply the fix. Log4j isn’t a piece of software you typically add to a project on purpose; it lives several layers deep, pulled in transitively by another library that no one on the team remembers choosing. By the time the fix was ready, teams were still asking, “Do we even have Log4j in our stack?”

This question – “what software do we actually run?” – is still the one most security teams can’t answer quickly. The answer, oddly enough, is both technically simple and politically messy: a Software Bill of Materials, or SBOM.

What exactly is an SBOM? Think of it as a nutrition label for code. It’s a structured, machine‑readable list that details every component, library, and version that makes up an application, plus – ideally – where each piece came from. NIST describes it as “a formal record containing the details and supply‑chain relationships of various components used in building software.” In plain English: it’s an exact ingredient list, so when a recall or vulnerability pops up you can spot the affected items in seconds instead of weeks.

Why is this conversation different today than it was in 2023? The shift started with Executive Order 14028, signed in May 2021 after the SolarWinds and Colonial Pipeline attacks. That order nudged federal agencies to require SBOMs from vendors, giving the concept a big regulatory push.

Fast forward to January 2026: the Office of Management and Budget issued Memorandum M‑26‑05, which quietly rescinded the earlier mandate (M‑22‑18) that forced agencies to collect standardized software security attestations. Now agencies can take a “risk‑based” approach, asking for SBOMs only when they think it’s necessary. The regulatory floor got softer, but the underlying risk – supply‑chain attacks – hasn’t disappeared.

This is actually a good moment to argue for SBOMs on their own merits – faster incident response and clearer attack‑surface visibility – rather than leaning on “the government says so.” For many companies, especially those outside the federal procurement arena, the requirement is no longer a hard‑stop but a strategic advantage.

To understand why SBOMs matter, let’s look at two real‑world supply‑chain incidents.

First, Log4Shell. A vulnerability in the Log4j logging library was exploited almost immediately after disclosure. The twist? Almost no one deliberately installed Log4j; it was embedded several dependencies deep, surfacing in products and services without anyone’s conscious decision. When the exploit wave hit, teams scrambled to locate the library, but without a pre‑existing inventory, the process was chaotic and slow.

Second, SolarWinds. Between late 2019 and early 2020, a sophisticated group (later attributed to Russia’s SVR) compromised the build environment of SolarWinds’ Orion software. They didn’t touch the source code; instead, they injected malicious code into the build pipeline, resulting in a signed, trojanized update that was silently delivered to roughly 18,000 downstream customers. Again, the victims had no real‑time, queryable list of what they were running, forcing them to cobble together a makeshift inventory under fire.

Both incidents share a common failure: the absence of an up‑to‑date, searchable software inventory. Organizations built those inventories after the fact, under pressure, and that’s exactly why an SBOM is valuable – it gives you a ready‑made map before a crisis hits.

There are two dominant SBOM formats today, and they’re less rivals than complementary tools. SPDX (Software Package Data Exchange) emerged from the open‑source licensing world and is now an ISO/IEC standard maintained by the Linux Foundation. CycloneDX, backed by OWASP, was designed with security in mind from day one, focusing on vulnerability tracking and runtime analysis. Both formats can be generated automatically by modern build systems and CI pipelines, making the creation of an SBOM less of a chore than it once seemed.

Implementing an SBOM isn’t just a checkbox exercise. It’s a cultural shift: teams need to treat their dependency graph as a living document, integrate SBOM generation into CI/CD, and make the data consumable for security tools, compliance checks, and even customers. The political debate around federal mandates may ebb and flow, but the technical reality remains clear – without an accurate, machine‑readable inventory, you’ll always be playing catch‑up after a supply‑chain breach.

So, five years on, the lesson is simple: know what you run, and know it now. An SBOM gives you that clarity, whether the pressure comes from a government memo or the next zero‑day that slides into the wild.