Part I: The Build You Can’t See Is the One That Will Kill You: Software Supply Chains, SBOMs, and the Long Reckoning After SolarWinds

There is a specific quality of dread that experienced security practitioners get when they think carefully about what happened in December 2020. Not the dread of a novel attack technique, or an adversary with exceptional resources. The dread of recognizing, in granular detail, exactly how many organizations were equally exposed and simply weren't targeted. The SolarWinds compromise — where a trojanized software update was distributed through a vendor's legitimate build pipeline and installed with full trust by thousands of downstream customers — was not primarily a story about sophisticated tradecraft. It was a story about the industry's collective decision to trust software artifacts it couldn't inspect, from processes it couldn't verify, at a scale that made the assumption catastrophically fragile.

Four years later, I want to report something encouraging: the reckoning has started. I want to be careful about how encouraging I make it sound, because the progress is real but the baseline was so poor that real progress still leaves us badly positioned.

What You're Actually Trusting When You Run a Container

Let me ground this concretely, because the abstraction of "software supply chain security" makes the problem feel larger and more theoretical than it is.

When an engineer pulls a container image from a registry and runs it in production, they are implicitly trusting: the base image and everything in it, every library and dependency pulled during the build, every tool that touched the build environment, the integrity of the registry itself, and the CI/CD pipeline that produced the image. In most organizations I've visited or spoken with, none of these trust relationships are verified at deployment time. The image runs because it's there and it has the right tag. Full stop.

This isn't carelessness — or not only carelessness. It's a rational response to a decade of tooling that made verification difficult and trust implicit. Container registries don't, by default, provide cryptographic guarantees about image provenance. CI pipelines don't, by default, produce signed attestations of what happened during the build. The path of least resistance has always been to pull and run.

What CISA recognized, in its updated guidance following the SolarWinds fallout, was that this path of least resistance had become a systemic vulnerability. Their framing — describing SBOMs as "foundational" to supply chain security — was notable precisely because it shifted the language from optional best practice to baseline expectation. For organizations selling software to the US federal government, that shift has teeth. For the broader enterprise market, it's creating regulatory pull that is accelerating adoption in ways that years of security conference talks didn't.

The SBOM: An Idea Whose Time Came at Enormous Cost

A Software Bill of Materials is, at its most mechanical level, a list. Every component in a software artifact — every library, every package, every dependency, with version numbers, license information, and ideally the provenance of where each came from. The concept isn't new. The automotive industry has maintained bills of materials for physical components for decades, because a recall without knowing which vehicles contain the affected part is an organizational catastrophe.

Software engineers resisted the analogy for a long time, and not entirely without reason. Software dependencies are more fluid than physical components, the graph of transitive dependencies can be genuinely enormous, and for most of computing history there was no standard format for expressing this information mechanically. The SBOMs that were produced manually were either incomplete, immediately stale, or both.

What changed the equation was tooling maturity. Instruments like Anchore's Syft — which can analyze a container image or filesystem and produce a complete SBOM in either the SPDX or CycloneDX standard format with a single command — made SBOM generation something a CI pipeline could do automatically at build time, for every artifact, without human involvement. The SBOM becomes an artifact of the build, produced and stored alongside the image it describes.

The utility becomes apparent the moment a new CVE is published. Before SBOMs, the standard enterprise response to something like Log4Shell — which emerged in December 2021 and affected applications that had pulled the library transitively, often without anyone knowing — was manual triage: engineers individually investigating whether their applications contained the vulnerable package, a process that took days or weeks across large organizations. With a maintained SBOM repository, the same analysis becomes a query. Which of our registered artifacts contain log4j-core in this version range? The answer comes back in seconds. The affected services are known. Remediation can be prioritized and tracked.

A vulnerability management lead at a large US healthcare technology company told me in August 2025 that their SBOM infrastructure, built out over the eighteen months following a board mandate in early 2024, had reduced their response time to critical CVEs by roughly 70%. She was careful to note that remediation still takes time — rebuilding and redeploying is not instantaneous — but the triage phase, which had previously been the dominant time sink, was now automated. She knew, within an hour of a CVE publication, exactly which services were affected and in what production environments.

Signing Is Not Bureaucracy. It's the Chain of Trust.

SBOMs tell you what's in an artifact. Signatures tell you whether you can trust the SBOM itself—and the artifact it describes.

Sigstore, the Linux Foundation project that has become the emerging standard for software artifact signing, addresses what was previously the most friction-heavy part of cryptographic signing: key management. Traditional GPG-based signing required managing long-lived private keys, distributing public keys through a web of trust, and maintaining the operational discipline to keep signing keys secure and rotated. In practice, most organizations skipped it because the overhead outweighed the perceived benefit.

Sigstore's Cosign tool uses ephemeral keys tied to OIDC identity — the CI pipeline's identity, specifically—and records signatures in a transparency log (Rekor) that makes it auditable and tamper-evident. The workflow becomes: build the artifact, generate the SBOM, sign both using the CI pipeline's identity, push everything to the registry. Anyone verifying the artifact can confirm that this specific image, with this specific content, was produced by this specific pipeline identity, and that the signature hasn't been altered since.

What this breaks is a specific and important attack path: the substitution of a malicious artifact after the build. If a registry is compromised, or an artifact is tampered with in transit, the signature verification fails at deployment. The image won't run. This is exactly the attack surface that SolarWinds exploited — a build artifact modified between production and distribution.

I want to be precise: Cosign doesn't prevent a malicious build. If the pipeline itself is compromised, the malicious artifact gets a legitimate signature. That's where SLSA — Supply-chain Levels for Software Artifacts — enters. SLSA is a framework for build provenance: cryptographic attestations that link a specific build artifact back to a specific source commit, run in a specific environment, with a specific set of build steps. At higher SLSA levels, these attestations are generated by the build system itself in a way that can't be forged by the build script. It's the difference between an artifact that claims to have been built from this commit, and one that can prove it.

The GitHub Actions Reality Check

Here is where I want to be honest about where the industry actually is, as opposed to where the framework documentation implies it should be.

SLSA Level 3 — the level that provides meaningful provenance guarantees, requiring that the build environment be isolated and the provenance be generated by the build platform rather than the build script — is achievable today on GitHub Actions with their new artifact attestation features, which reached general availability in mid-2024. On other platforms, the path is more complex.

Most organizations are not at SLSA Level 3. Many are not at Level 1, which requires only that provenance documentation exists in some form. The gap between policy aspiration and operational reality is substantial, and I've watched enough organizations try to close it to have a realistic sense of what it takes.

The organizations making genuine progress share a few characteristics. They've treated SBOM generation and signing as infrastructure requirements rather than security theater — meaning they've built them into platform templates that every team gets automatically, rather than requiring individual teams to implement them. They have an SBOM repository that's actually being used: queried during vulnerability response, checked during compliance reviews, updated on every build rather than on an annual audit cycle. And they have signing verification enforced at deployment time — an admission controller or equivalent that simply won't run an image that lacks a valid signature from an authorized build pipeline.

A DevSecOps engineer at a financial services firm in Toronto laid it out plainly during a conversation in October 2025: "The SBOM generation took us a week to implement. Signing took two weeks. Getting enforcement turned on in production took four months, because that's when you find out which of your legacy services don't have build pipelines that can be modified, and which teams have been pulling images from registries that aren't in scope for signing."

That four months is the realistic part. The tools are good. The organization is the hard problem.

What Compliance Is Getting Right and Getting Wrong

Executive Order 14028, signed in May 2021 and still being operationalized through CISA guidance and NIST frameworks, has had a measurable effect on enterprise practice — particularly for organizations in or adjacent to the federal contracting space. The requirement to provide SBOMs for software delivered to government customers has created a forcing function that years of voluntary best practice guidance didn't.

The risk, which I've watched materialize in real procurement conversations, is that SBOM compliance becomes a checkbox rather than a capability. An organization produces SBOMs because a contract requires them, stores them in an archive nobody queries, and considers the obligation discharged. The SBOM exists. It is never used. It becomes documentation rather than infrastructure.

The difference between an SBOM program and SBOM documentation is whether the SBOMs are integrated into the response workflows that matter: vulnerability triage, incident response, compliance reporting, and deployment policy. If your SBOM is a file attached to a contract deliverable but not connected to the system that decides whether an image can be deployed, you have not improved your security posture. You've improved your audit posture. These are not the same thing.