The long, opaque road from source to runtime
Every piece of software begins as source code—plain text files in a repository—and is later transformed through a build process into something executable: minified JavaScript, a container image, or a compiled binary. That final product, the software artifact, typically sits at rest in a package registry, container registry, or blob store until someone decides to run it.
The journey from source to running artifact can involve many hours of human effort and significant expense. Yet in many cases, there is no strong guarantee that the artifact being executed is actually the one that was built. The details of its path are lost or hazy, making it hard to connect the artifact back to its source code and build instructions. This visibility gap is at the heart of many of today’s most pressing software supply chain security challenges. Fortunately, this problem is solvable.
Digests and signatures: the first layer of trust
A good starting point for verifying an artifact’s integrity is generating a digest—a hash—of the file using a secure algorithm. For example, using OpenSSL with SHA-256:
openssl dgst -sha256 ~/important-file.txt
This produces a 64-character string that serves as a unique fingerprint for the file. Change anything in the file and the hash changes. Store the digest somewhere, re-run the hash later, and a mismatch reveals tampering.
But a digest alone only proves a file hasn’t changed since the hash was computed. To make a statement about an artifact’s origin—to say “a trusted entity saw this exact thing”—you need a signature. This involves running the digest through an asymmetric cryptographic algorithm: sign the hash with a private key, distribute the corresponding public key, and anyone can verify the file came from you.
Asymmetric encryption already underpins trust on the internet, from TLS to SSH. Operating systems like Windows, macOS, iOS, and Android all enforce signature checks on executable artifacts to ensure trusted origins. Building these systems is notoriously difficult, but they are foundational to modern software security.
From signatures to attestations
Signatures say “some trusted system saw this thing,” but supply chain security demands more. A more robust approach involves attestations: signed statements about an artifact created by an authenticated entity. The most critical type is a provenance attestation, which asserts facts about the artifact’s origin—the source repository and the build process that produced it.
The specification used here comes from the SLSA project, which provides a vendor-neutral framework for reasoning about supply chain security guarantees. SLSA’s provenance schema builds on work from the in-toto project, a CNCF-graduated effort that standardizes metadata for supply chain and build process information.
Building an attestation service
Creating a service that can generate and verify these attestations requires several components: a Certificate Authority (CA) to issue certificates binding public keys to authenticated identities; a client application for signing; and mechanisms to prevent certificate misuse, either through revocation lists or short-lived certificates backed by a timestamping authority. The latter approach avoids the need for ongoing revocation management.
Sigstore, an open source project, provides both an X.509 CA (Fulcio) and an RFC 3161-compliant timestamp authority. It also integrates with OIDC tokens, which many CI systems already generate and associate with their workloads. This design aims to make software signing as simple and transparent as Let’s Encrypt made TLS certificates.
Sigstore relies on The Update Framework (TUF) for a secure root of trust, allowing clients to handle key rotations without code updates. TUF mitigates a range of attack vectors associated with in-place updates, and is used by projects delivering firmware updates, telemetry agents, and other long-running components.
With Sigstore in place, it becomes possible to create a tamper-proof trail linking artifacts back to their CI pipeline. That traceability gives software consumers the means to enforce their own policies about what code they will execute, based on verified provenance rather than assumption.
