Apache disclosed Log4Shell on December 9–10, 2021. As I write this, that's closing in on five years ago — long enough that it should be ancient history, a war story security teams tell new hires. It isn't. Talk to anyone who was on call that week and you'll hear the same detail every time: patching wasn't the hard part. Alibaba's Chen Zhaojun had reported the flaw responsibly on November 24; within hours of the public disclosure, mass scanning and exploitation were already underway, and CISA and the wider Joint Cyber Defense Collaborative were coordinating an emergency response. The vulnerability itself scored a maximum 10.0 on the CVSS scale. Early U.S. government estimates, reported by the Wall Street Journal, put the number of potentially exposed devices in the hundreds of millions. And the hardest part, for most organizations, wasn't applying the fix once they knew where it was needed. It was figuring out where it was needed — because Log4j wasn't something teams had installed on purpose. It was buried three, four, five dependencies deep, pulled in transitively by some other library nobody remembered choosing.That's the thesis of this piece: most organizations still can't answer "what software do we actually run" quickly, and the fix — a Software Bill of Materials — is both simpler and more contested than most teams realize. Simpler technically. More contested politically, as of this year, which we'll get to.What an SBOM actually isA Software Bill of Materials is a structured, machine-readable inventory of every component and dependency in a piece of software — libraries, versions, and, ideally, where each one came from.The nutrition-label comparison gets used constantly in this space because it's accurate: an SBOM isn't "contains flour," it's the exact ingredient list, versioned and sourced, so you can check it against a recall notice in seconds instead of weeks. NIST's own framing, from its EO 14028 guidance, describes an SBOM as a "formal record containing the details and supply chain relationships of various components used in building software" — which is a more bureaucratic way of saying the same thing.Why this is more contested now than it was a year agoHere's the part that's genuinely shifted, and it's worth being precise about it rather than repeating the version of this story that was true in 2023.Executive Order 14028, signed in May 2021 after SolarWinds and Colonial Pipeline, is what put SBOMs on the map for U.S. federal procurement. It directed NIST and NTIA to define minimum elements for an SBOM and pushed agencies toward requiring them from software vendors. That order itself hasn't been rescinded and technically remains in effect. But the implementing guidance under it has moved substantially. In January 2026, the Office of Management and Budget issued Memorandum M-26-05, rescinding the prior mandate (M-22-18) that required agencies to collect standardized software security attestations from vendors. The new posture gives agencies discretion to take a "risk-based approach" instead of a uniform requirement — agencies are no longer required to obtain those attestations by default, though they still may request them, and cloud providers can still be asked for a runtime SBOM on request.What that means in practice: the regulatory floor got softer, not the underlying risk. The SolarWinds and Log4Shell incidents that justified SBOM adoption in the first place didn't become less real because a procurement memo changed. If anything, the softer federal mandate is a good moment to make the actual argument for SBOMs on its merits — incident response speed and attack-surface visibility — rather than leaning on "the government requires it," because for a lot of organizations, strictly speaking, it currently doesn't.The threat model, in two real incidentsIt's worth being precise about the mechanism, because "supply chain attack" gets used loosely. The attacker isn't targeting your code. They're targeting a dependency, or the pipeline that builds and signs your code, which you trust by default.Log4Shell is the first pattern: a vulnerability in a component so widely embedded that almost nobody who was exposed had made a direct, conscious decision to use it. Log4j is a logging library — the kind of dependency that ships inside other dependencies, inside vendor products, inside your own code, often without anyone on a given team knowing it's there. That's precisely why an inventory-after-the-fact response took so long: there was no existing map to consult.SolarWinds is the second, structurally different pattern. Between roughly September 2019 and March 2020, attackers — later attributed to Russia's SVR (APT29) — compromised SolarWinds' build environment itself, using malware (tracked as SUNSPOT) that watched for the Orion product's build process and injected the SUNBURST backdoor directly into the compiled output before it was signed. SolarWinds has stated the attackers did not modify the source repository — the tampering happened inside the automated build pipeline. Roughly 18,000 organizations downloaded a trojanized, validly-signed Orion update between March and June 2020, and the backdoor sat undetected until FireEye discovered it in its own environment and disclosed the breach in December.Both incidents share the same underlying failure: neither organization, nor most of their downstream customers, had a reliable, queryable inventory to consult when the incident broke. They built one under pressure, during the fire.SBOM formats, demystifiedTwo formats dominate current tooling, and they're not really competitors so much as different starting points. SPDX (Software Package Data Exchange), an ISO/IEC standard maintained under the Linux Foundation, grew out of software licensing and compliance work. CycloneDX, backed by OWASP, was designed from the start with security use cases in mind — vulnerability tracking, not just license auditing. Both are widely supported by current generation tooling; which one you pick often comes down to whether your primary driver is compliance/licensing or security operations. SWID tags exist as a third, older format, mostly relevant in enterprise asset-management contexts — worth knowing the name, not worth building a strategy around.Generating and using SBOMs in an actual pipelineThe concrete version of this, not the slideware version: on every build, an SBOM-generation step scans the build artifact and produces a structured SBOM file. A vulnerability scanner then checks that SBOM against a live vulnerability database, and the pipeline fails the build if it finds something critical and unpatched.Anchore's Syft and Grype are the open-source pair most teams reach for first. The real, current commands look like this:# Generate an SBOM from a directory, container image, or filesystemsyft . -o spdx-json > sbom.json# Scan a previously generated SBOM for known vulnerabilitiesgrype sbom:./sbom.jsonNote the sbom: prefix on the second command — that tells Grype it's reading a pre-generated SBOM file rather than scanning a live target directly, which matters because scanning the stored SBOM (instead of re-scanning the artifact every time) is what lets you cheaply re-check old releases against newly disclosed CVEs later, without rebuilding anything.As a CI step, wired into GitHub Actions, it looks roughly like this:- name: Generate SBOM run: syft . -o spdx-json > sbom.json- name: Scan SBOM for vulnerabilities run: grype sbom:./sbom.json --fail-on critical- name: Upload SBOM as build artifact uses: actions/upload-artifact@v4 with: name: sbom path: sbom.jsonThat last step is the one teams skip and shouldn't. Storing the SBOM as a build artifact, tied to the release it describes, is what turns "are we affected by the next Log4Shell" from a multi-week fire drill into a query against files you already have.Beyond generation: signing and provenanceKnowing what's in your software doesn't help if you can't also prove the artifact wasn't tampered with between your pipeline and your customer — which is exactly what the SolarWinds attack demonstrated. This is where artifact signing and SLSA (Supply-chain Levels for Software Artifacts) come in. SLSA, originally developed at Google and now maintained by the OpenSSF, reached its 1.0 specification in April 2023, defining a tiered ladder of build-integrity requirements — from "the build has some provenance" up to "the signing happens inside an isolated, tamper-resistant build platform that even a malicious insider can't forge."Sigstore is the toolchain most current SLSA adoption leans on, and its "keyless" signing model is worth understanding because it directly answers the failure mode SolarWinds exposed: instead of a long-lived private key that becomes a single point of catastrophic failure if stolen, a CI job authenticates via OIDC, gets a short-lived certificate from Sigstore's Fulcio, signs the artifact with cosign, and the signing event is recorded permanently in Sigstore's public Rekor transparency log. A real signing command looks like:cosign sign --yes myregistry/myapp@sha256:No key management, no rotation schedule — the identity comes from the CI workflow itself, and the log means a forged signature would be publicly detectable rather than silently trusted.Continuous monitoring, not a one-time scanAn SBOM generated once at build time starts going stale the moment a new CVE is published against a library you already shipped six months ago. The practical shift is toward continuously re-scanning stored SBOMs from past releases against live, updating vulnerability feeds — not just gating new builds. A scheduled job that re-runs Grype against every SBOM in your artifact store, daily, against the current vulnerability database, is what actually closes the Log4Shell gap: the day a library you shipped gets a new critical CVE, you find out from your own pipeline instead of from a headline.A realistic starting pointAdd SBOM generation to CI for one flagship application first. Syft, storing output as a build artifact. This is genuinely a same-day task, not a quarter-long initiative.Add vulnerability scanning as a non-blocking step initially. Run Grype against the SBOM, but don't fail builds yet — you need to see what it actually surfaces and tune out noise before you let it gate anything.Once the false-positive rate is understood, make critical findings a blocking check.Add artifact signing once SBOM generation is routine, not before. Signing an unreliable inventory just adds ceremony without adding trust — sequencing matters here.ClosingThe organizations that answered "are we exposed" in hours instead of weeks when Log4Shell broke weren't lucky. They already had an inventory to query, built before the incident instead of during it. The federal mandate that helped popularize SBOMs has gotten discretionary rather than mandatory this year — which makes this a reasonable moment to ask why you were actually doing it. If the honest answer was always "so we're not building the map during the fire," that reason didn't change with a procurement memo.SourcesCISA, "Apache Log4j Vulnerability Guidance"Cyber Safety Review Board, Review of the December 2021 Log4j Event (July 11, 2022)CISA, "Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations" (SolarWinds/SUNBURST advisory)SolarWinds, "An Investigative Update of the Cyberattack"NIST, "Software Security in Supply Chains: Software Bill of Materials (SBOM)"Wiley, "OMB Rescinds Secure Software Development Mandate in Favor of a Risk-Based Approach" (Jan 2026)Davis Wright Tremaine, "OMB Rescinds Biden-Era Software Security Requirements"Anchore, Syft and Grype official documentationSLSA, slsa.dev official framework documentation