The End of Static Keys: Why Sigstore Matters Now

After twenty-five years in enterprise banking, I have watched the software supply chain evolve from a simple trust exercise to a complex web of dependencies and potential attack vectors. In the early days, we relied on GPG keys—static, long-lived, and increasingly difficult to manage securely. Today, the industry is moving toward ephemeral, OIDC-based identities. Sigstore is not just a tool; it is the emerging standard for proving that code came from where it claims to have come from.

In 2026, the expectation is no longer just "is the code signed?" but "who signed it, and can we cryptographically verify the entire build process?" This is where Sigstore, with its transparency log (Rekor) and certificate authority (Fulcio), becomes critical. We are moving away from shared secrets toward a model where every build is uniquely identified and attested.

Understanding the SLSA Framework

Security Level Assurance (SLSA) provides a structured approach to supply chain security. It is not a product but a framework that defines what we need to achieve. The core premise is simple: the higher the security level, the more assurance we have that the software has not been tampered with.

We categorize security into levels based on the integrity of the build environment and the provenance:

  • SLSA 1: Build provenance exists. We know what went into the build, but the process is not fully automated or isolated.
  • SLSA 2: Build provenance is generated by a hosted CI/CD system. The identity is managed by the provider, reducing the risk of key theft.
  • SLSA 3: Build provenance is generated by a hosted CI/CD system with unique, unpredictable build identifiers. This prevents pre-building attacks.
  • SLSA 4: Build provenance is generated by a hosted CI/CD system with strict source code integrity. The build environment is ephemeral and isolated.

For enterprise workloads, particularly in financial services, we are targeting SLSA 3 and 4. The goal is to ensure that the binary running in production is identical to the one built in the CI pipeline, with no possibility of substitution.

Implementing Sigstore in Your Pipeline

Integrating Sigstore is straightforward if you understand the components. You need three things: an identity provider (OIDC), a signing tool (cosign), and a verification step. The key players are Fulcio, which issues short-lived certificates, and Rekor, which logs the transparency data.

Here is how I structure a typical pipeline integration for a Go or Java application:

  1. OIDC Exchange: The CI/CD runner (GitHub Actions, GitLab CI, or Jenkins) exchanges its OIDC token for a short-lived certificate from Fulcio. This replaces the need for a static signing key.
  2. Signing: Using cosign, the build artifact is signed with the ephemeral certificate. The signature is bound to the specific commit SHA and build ID.
  3. Transparency Log: The signature and metadata are uploaded to Rekor. This creates an immutable record that can be audited later.
  4. Attestation: Alongside the signature, we generate a SLSA attestation file (in JSON format) that describes the build process, including the builder ID, build configuration, and materials.

This process ensures that every artifact has a cryptographic link to its build event. If someone tries to modify the binary after the build, the signature will fail verification. If someone tries to forge the signature, they would need the private key, which never leaves the ephemeral CI environment.

Verifying Attestations at Runtime

Signing is only half the battle. You must verify the attestation before deploying or running the artifact. In a Kubernetes environment, this often means using an admission controller or a runtime security tool that checks the signature against the Rekor transparency log.

The verification process involves checking three things:

  • Signature Validity: Is the signature valid for the artifact?
  • Identity Trust: Is the certificate issued by a trusted Fulcio instance?
  • Transparency: Is the signature present in the Rekor log, ensuring it hasn’t been deleted or altered?

I recommend implementing this verification at the edge, in your ingress controllers or service meshes, as well as at the node level. This creates a defense-in-depth strategy. If a compromised image slips through, the runtime verification will catch the anomaly.

Common Pitfalls and Best Practices

In my experience, the biggest challenge is not the technology but the process. Teams often try to bolt Sigstore onto legacy pipelines without refactoring the build process. This leads to "security theater" where the attestation exists but is not meaningful.

Ensure that your build environment is truly ephemeral. Do not reuse runners with persistent state. Use containerized build steps to isolate the environment. Also, be mindful of the metadata you include in the attestation. Too little information makes verification difficult; too much can leak sensitive information.

For more details on container supply chain security, I recommend reading our previous analysis on Container Supply Chain Security 2026, where we discuss image scanning and policy enforcement in depth.

Frequently Asked Questions

What is the difference between Sigstore and SLSA?

Sigstore is the toolset (Rekor, Fulcio, cosign) that provides the infrastructure for signing and transparency. SLSA is the framework that defines the security levels and requirements for the build process. You use Sigstore to implement SLSA.

Can I use Sigstore with private repositories?

Yes. While Rekor is a public transparency log, the signing process and the attestation data can be kept private. You can run your own Fulcio instance and Rekor server within your VPC for maximum security and compliance.

How long are the certificates valid?

Certificates issued by Fulcio are short-lived, typically valid for only 10 minutes. This minimizes the window of opportunity for key compromise and eliminates the need for key rotation.

Is Sigstore compatible with Kubernetes?

Yes, Sigstore integrates well with Kubernetes. Tools like cosign can verify images before they are pulled, and admission controllers can enforce signature policies at deployment time.