Securing the Software Supply Chain: Sigstore, SLSA, and the New Container Trust Model

The SolarWinds attack of 2020 was a turning point. Attackers did not breach the target organizations directly. They compromised the software build pipeline of a trusted vendor, inserted malicious code into a legitimate software update, and distributed it to thousands of customers who had every reason to trust what they were installing. The hack compromised the US Treasury, the Department of Homeland Security, and hundreds of private sector organizations. The damage was not a consequence of weak passwords or unpatched servers — it was a consequence of the software supply chain being fundamentally untrustworthy.

That realization has driven one of the most consequential infrastructure security movements of the 2020s. In 2026, the software supply chain security stack — Sigstore for artifact signing, SLSA for build integrity attestation, SBOMs for dependency transparency, and hardened container registries — has matured from research projects into production requirements at serious engineering organizations.

The Problem That SolarWinds Made Undeniable

Modern software is not written from scratch. It is assembled. A typical enterprise application pulls hundreds of open-source dependencies, which themselves pull hundreds more. The average application has more lines of third-party code than first-party code. Each of those dependencies is a potential attack vector.

The Log4Shell vulnerability of late 2021 demonstrated this with terrifying clarity. A critical flaw in Log4j, a ubiquitous Java logging library used in everything from enterprise servers to embedded systems, exposed hundreds of millions of applications globally. The problem was not that Log4j was poorly known — it was everywhere precisely because it was trusted and widely adopted. Its ubiquity was the vulnerability surface.

The dependency attack model has since proliferated. Malicious packages uploaded to npm, PyPI, and RubyGems — deliberately named to resemble popular legitimate packages (typosquatting) — have become a routine threat vector. Supply chain attacks grew by over 730% between 2019 and 2022 according to Sonatype’s annual State of the Software Supply Chain report, and the trend has continued upward.

Sigstore: Signing Everything, Trusting Nothing Unsigned

Sigstore is a Linux Foundation project that provides free, open infrastructure for signing software artifacts — container images, binaries, build attestations — and verifying those signatures transparently. The core insight is that software provenance (where something came from and who built it) should be as verifiable as HTTPS certificates on websites.

The traditional approach to code signing required managing private keys, which is genuinely hard to do securely at scale. Keys get leaked, lost, or rotated inconsistently. Sigstore’s solution is to use short-lived certificates tied to an OIDC identity (a developer’s GitHub or Google identity) rather than long-lived private keys. The signing event is recorded in a public, append-only transparency log called Rekor, which allows anyone to verify that a specific artifact was signed by a specific identity at a specific time.

By 2025, Sigstore had processed billions of signatures. The Python Package Index (PyPI) began rolling out Sigstore-based provenance attestations. GitHub integrated Sigstore into its Actions workflows, allowing any repository to generate signed build attestations automatically. The GitHub npm registry followed. For any organization pulling packages from these registries, the infrastructure to verify that a package was genuinely built from the stated source code — and not tampered with in transit — now exists and is increasingly the expected baseline.

SLSA: Levels of Build Integrity

Sigstore tells you who signed an artifact. SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) tells you how trustworthy the build process that produced it was. SLSA is a framework developed at Google and now stewarded by the OpenSSF (Open Source Security Foundation) that defines four graduated levels of supply chain security.

At SLSA Level 1, builds are documented. At Level 2, builds are version-controlled and use a build service. At Level 3, the build service is hardened against tampering — sources and build steps are recorded in verifiable provenance. Level 4 (the most stringent, not yet widely adopted) requires two-party review of all changes and a hermetic, reproducible build process.

The practical effect is that SLSA gives procurement teams, security auditors, and platform engineers a vocabulary for asking “how trustworthy is this artifact?” instead of simply “was it signed?” A container image built from an ephemeral, isolated build environment with recorded provenance at SLSA Level 3 is meaningfully more trustworthy than one built locally on a developer’s laptop and pushed directly to a registry, regardless of whether both are signed.

Major cloud providers have moved to support SLSA attestations natively. Google Cloud Build generates SLSA Level 3 provenance. GitHub Actions supports SLSA attestation generation. The US federal government’s Executive Order on Improving the Nation’s Cybersecurity mandated NIST guidelines that align with SLSA principles for software procured by federal agencies.

SBOM Mandates: Knowing What Is in Your Software

A Software Bill of Materials (SBOM) is a machine-readable inventory of all the components in a piece of software — its direct dependencies, their transitive dependencies, their versions, and their known license obligations. The concept is borrowed from manufacturing, where a bill of materials is a standard document.

The US executive order of May 2021 made SBOMs mandatory for software sold to the federal government. The EU Cyber Resilience Act, which entered into force in 2024, extends similar requirements broadly across software products sold in the EU market. In 2026, producing and consuming SBOMs is rapidly becoming a standard engineering practice at organizations that take supply chain risk seriously, not merely a compliance checkbox.

The two dominant SBOM formats are SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Most major build tools and CI/CD platforms now have plugins or native support for generating SBOMs automatically as part of the build process. The hard work is not generating the SBOM — it is operationalizing it: integrating SBOM data into vulnerability management workflows so that when a new CVE appears in a transitive dependency, engineering teams receive actionable alerts rather than generic scanner noise.

Container Trust and the Registry Security Model

Containers have become the dominant software packaging and deployment unit. Container images, however, are themselves software supply chain artifacts: a Dockerfile references a base image from a registry, which was built from source code, which pulls its own dependencies. Each layer is a potential attack surface.

The response has been a hardening of container registries and the workflows surrounding them. Cosign, part of the Sigstore project, allows container images to be signed and their signatures stored in an OCI-compatible registry. Policy enforcement tools like Kyverno and OPA/Gatekeeper allow Kubernetes clusters to reject unsigned or unattested container images at admission time — preventing unverified images from running in production regardless of what developers or automated systems attempt to deploy.

The concept of a “trusted builder” — an ephemeral, isolated, auditable CI/CD environment that produces signed artifacts with recorded provenance — has moved from theoretical best practice to operational requirement at high-security environments. The supply chain security stack is becoming infrastructure: invisible when working correctly, catastrophic when absent.

Frequently Asked Questions

Sources & Further Reading

• SLSA Framework — Official Documentation (OpenSSF)
• Sigstore — Free Software Signing for Everyone
• State of the Software Supply Chain Report — Sonatype
• Securing the Software Supply Chain — CISA
• S2C2F: Secure Supply Chain Consumption Framework — OpenSSF
• Executive Order on Cybersecurity & SBOM Requirements — NIST