Verifying What You Ship: Cryptographic Attestation and the Fight to Secure the Software Supply Chain

For decades, the dominant model of software consumption operated on a form of institutional faith. Organizations downloaded packages from registries, pulled container images from public repositories, and integrated third-party libraries into production systems with varying degrees of scrutiny. The assumption, rarely articulated but pervasive, was that the code arriving at the build pipeline was the code its authors intended to publish. That assumption has proven costly.

The 2020 compromise of SolarWinds' Orion build environment did not merely expose one vendor's security posture. It demonstrated, with uncomfortable clarity, that sophisticated threat actors had recognized the software supply chain as a high-leverage attack surface — one where a single successful intrusion could propagate malicious code to thousands of downstream organizations simultaneously. The incident prompted a fundamental reassessment of how software provenance should be established and verified.

The Anatomy of a Supply Chain Attack

Understanding why cryptographic verification matters requires understanding how supply chain attacks are constructed. Unlike direct intrusion campaigns, which target the defender's environment, supply chain attacks target the trust relationships that defenders have already established with external parties. By compromising a build system, a package registry, or a dependency update mechanism, an attacker can deliver malicious code through a channel the target organization has explicitly authorized.

The attack surface is broad. Dependency confusion attacks exploit how package managers resolve namespace conflicts between public and private registries. Typosquatting campaigns register packages with names nearly identical to legitimate libraries, waiting for developers to mistype a dependency name. Build system compromises — the most technically demanding but also the most impactful variant — involve inserting malicious modifications into software during the compilation or packaging process, producing artifacts that diverge from the source code even when that source code has not been tampered with.

Each of these vectors shares a common characteristic: they exploit the gap between what an organization believes it is deploying and what it is actually executing. Cryptographic verification is the technical mechanism for closing that gap.

Software Bills of Materials: Inventory as a Security Primitive

Before an organization can verify the integrity of its software components, it must know what those components are. The Software Bill of Materials — commonly abbreviated as SBOM — provides that inventory. Structured as a machine-readable document listing the components, dependencies, and metadata associated with a software artifact, the SBOM enables organizations to assess exposure when a vulnerability is disclosed in a specific library, and to verify that the components declared in the SBOM correspond to what was actually incorporated into a build.

The Biden administration's 2021 Executive Order on Improving the Nation's Cybersecurity elevated the SBOM from a niche supply chain concept to a federal procurement requirement, directing agencies to develop minimum standards for SBOM content and mandating their provision by software vendors selling to the federal government. The two dominant SBOM formats — CycloneDX, maintained by the OWASP Foundation, and SPDX, developed under Linux Foundation governance — have both matured substantially in the years since, with tooling ecosystems that now support automated SBOM generation as part of CI/CD pipelines.

However, an SBOM alone does not establish trust. A document listing components can itself be falsified or can describe components that were modified after the document was generated. The SBOM derives its security value from being bound to the artifact it describes through cryptographic attestation.

Signing, Attestation, and the Sigstore Ecosystem

Code signing — the practice of applying a cryptographic signature to a software artifact so that its origin and integrity can be verified — is not a new concept. Package managers including RPM and Debian's APT have supported signing for many years. What has changed is the emergence of more comprehensive attestation frameworks and the infrastructure required to make signing practical at scale.

Sigstore, a Linux Foundation project that has attracted contributions from Google, Red Hat, and Chainguard among others, represents the most significant recent development in open-source supply chain signing infrastructure. Its core components — Cosign for signing container images and other artifacts, Fulcio as a certificate authority that issues short-lived signing certificates tied to verified identities, and Rekor as a tamper-evident transparency log recording signing events — collectively provide a framework for establishing and verifying artifact provenance without requiring organizations to operate complex key management infrastructure independently.

The SLSA framework (Supply-chain Levels for Software Artifacts), developed initially at Google and now stewarded as an open specification, complements signing by defining a tiered maturity model for build provenance. SLSA levels progress from basic source version control practices at Level 1 to hermetically reproducible, isolated builds with fully attested provenance at Level 4. The framework provides organizations with a structured vocabulary for assessing the provenance guarantees offered by their software suppliers.

Implementation Realities

The gap between theoretical supply chain security and operational implementation is significant. Organizations that have attempted to enforce signature verification as a hard gate in their deployment pipelines frequently encounter artifacts from upstream dependencies that lack valid signatures, creating a choice between blocking legitimate software and creating exceptions that undermine the policy's value.

A pragmatic implementation strategy typically begins with the organization's own first-party artifacts. Establishing signing practices for internally produced container images, libraries, and deployment packages before extending verification requirements to third-party dependencies allows teams to build operational familiarity with signing workflows and verification tooling without immediately confronting the ecosystem coverage gaps that exist in public registries.

Policy enforcement through admission controllers in Kubernetes environments — using tools such as Kyverno or the Open Policy Agent Gatekeeper — allows organizations to enforce signature verification requirements at the point of deployment, rejecting workloads whose images cannot be verified against a trusted signing key or transparency log entry. This approach shifts verification from a manual, audit-oriented activity to an automated, enforcement-oriented one.

The Trajectory of the Field

The software supply chain security discipline has matured considerably since the SolarWinds incident brought it to mainstream attention. The CISA and NIST frameworks that have emerged in the years since reflect an industry that is moving from awareness to implementation — from understanding that supply chain provenance is a problem to developing the tooling, standards, and operational practices required to address it systematically.

What the field has not yet resolved is the coordination problem: the value of cryptographic attestation scales with the breadth of its adoption. An organization that verifies signatures on its own artifacts but cannot obtain verified provenance from the majority of its dependencies has improved its posture at the margins. Closing the supply chain risk gap at scale will require the same kind of ecosystem-wide adoption that took decades to achieve for transport layer encryption — a precedent that offers both encouragement and a realistic measure of the work that remains.