Understanding Software Supply Chain Security: Hashes, Signatures, and Provenance with SLSA and Sigstore

Software is a fascinating and deep construct made of seemingly magical code snippets that run on terminals; while not alive, it possesses its own lifecycle.

Initially, software exists as source code stored in a repository. Through a build process, this source is transformed into other forms such as compressed JavaScript bundles for web servers, container images that include framework code and business logic, or native binaries compiled for specific processor architectures.

These transformed outputs are called “software artifacts.” After creation, artifacts typically remain dormant, awaiting use. They may be stored in package registries (e.g., npm, RubyGems, PyPI), container registries (e.g., GitHub Packages, Azure Container Registry, AWS ECR), attached to GitHub releases as binaries, or simply kept as ZIP files in blob storage.

Eventually, someone retrieves an artifact, unpacks it, executes the code, starts a container, installs a driver, or updates firmware, causing the built software to run.

This marks the peak of the production lifecycle, a process that can require massive human effort and financial investment, underscoring its critical importance in a world that depends on software.

In many cases, however, we cannot be certain that the running artifact is exactly the one we built; provenance details are often lost or blurred, making it difficult to link an artifact back to its source code and build instructions.

The lack of visibility into an artifact’s lifecycle is the root of many severe security challenges. Protecting the transformation from code to artifact throughout the Software Development Lifecycle (SDLC) can eliminate the risk of threat actors tampering with final software.

Hash Values and Signatures

To verify that a file remains unchanged from one day to the next, a secure hash algorithm can generate a hash value for the file.

Using OpenSSL with SHA‑256, the command is:

openssl dgst -sha256 ~/important-file.txt

The resulting 64‑character string uniquely fingerprints the file; any modification produces a different hash, allowing detection of tampering.

Beyond detecting changes, signing an artifact involves encrypting its hash with a private key, producing a signature that can be verified with the corresponding public key. This asymmetric cryptography underpins trust on the internet, enabling secure interactions such as TLS and SSH.

Operating systems like Windows, macOS, iOS, and Android enforce signed executables to ensure trustworthy origins.

Not Just Signatures – Also Attestations

While signatures confirm that a trusted system has seen an artifact, true security progress requires attestations—cryptographically signed statements about an artifact’s provenance, created by a verifiable entity.

The most fundamental attestation type is a provenance claim that links an artifact to the source code and the build instructions that produced it.

We adopt the SLSA (Supply‑Chain Levels for Software Artifacts) framework for such provenance. SLSA, built on the in‑toto project, defines a standardized metadata schema for supply‑chain and build processes.

What Is Needed to Build This?

GitHub, as the world’s largest code‑hosting and CI platform, provides the infrastructure for secure artifact signing. The required components include:

Issuing certificates bound to authenticated identities.

Ensuring certificates cannot be misused.

Enabling secure signing of artifacts in known contexts.

Allowing end‑users to verify those signatures.

This involves a Certificate Authority (CA) and a client application to verify signatures.

To prevent certificate abuse, one must maintain revocation lists or use short‑lived certificates backed by a timestamp authority.

Sigstore fulfills this role as an open‑source project offering an X.509 CA, RFC 3161 timestamping, and OIDC‑based authentication, making software signing as simple and transparent as Let’s Encrypt does for TLS certificates.

GitHub helps govern Sigstore, contributing server‑side applications and client libraries, and collaborates with organizations like Chainguard, Google, Red Hat, and Stacklok to operate the public‑good instance of Sigstore.

Sigstore also complies with The Update Framework (TUF), providing a secure trust root that allows clients to follow CA key rotations without updating code, mitigating many supply‑chain attacks.

With Sigstore, artifacts can be cryptographically linked to CI pipelines, giving consumers the ability to enforce their own policies about the origin of the code they execute.

Original source: https://github.blog/2024-04-30-where-does-your-software-really-come-from/

References

[1] SLSA project: https://slsa.dev/

[2] in‑toto project: https://in-toto.io/

[3] Certificate Authority (CA): https://en.wikipedia.org/wiki/Certificate_authority

[4] Sigstore: https://www.sigstore.dev/

[5] OIDC token: https://www.microsoft.com/en-us/security/business/security-101/what-is-openid-connect-oidc

[6] Let’s Encrypt: https://letsencrypt.org/

[7] The Update Framework (TUF): https://theupdateframework.org/