Sigstore and Cosign: Software Signing for the Rest of Us

Why Software Signing Was Broken

Code signing has existed for decades. The concept is simple: sign your software artifacts with a cryptographic key, so consumers can verify they came from you and weren't tampered with. PGP has been used to sign Linux packages since the 1990s. Microsoft Authenticode signs Windows binaries. Apple codesign protects macOS applications.

So why don't most open-source projects sign their releases?

Because traditional signing is a nightmare. You need to generate key pairs, distribute public keys through some trusted channel, protect private keys from compromise, rotate keys when they're exposed, and revoke keys when they're lost. Most individual developers and open-source maintainers simply don't do it. The barrier is too high.

The result: most npm packages, Docker images, Python wheels, and Go binaries are distributed unsigned. When you run npm install or docker pull, you're trusting the registry's integrity without any independent cryptographic verification.

Sigstore was created to fix this.

What Is Sigstore?

Sigstore is an open-source project under the Linux Foundation, originally created by Google, Red Hat, and Purdue University. Its goal is to make software signing and verification as easy as HTTPS made encrypted web traffic.

The project consists of three core components:

Cosign: Container Signing

Cosign is the signing tool. It signs container images, blobs, and other OCI artifacts. The breakthrough is "keyless signing" — instead of managing long-lived key pairs, developers authenticate with their identity provider (GitHub, Google, Microsoft) and get a short-lived signing certificate.

Signing a container image with Cosign:

cosign sign --yes ghcr.io/myorg/myimage:v1.0

This opens a browser for OIDC authentication, obtains a short-lived certificate, signs the image, and uploads the signature and certificate to the transparency log. No key management required.

Verifying a signed image:

cosign verify --certificate-identity developer@company.com \
  --certificate-oidc-issuer https://accounts.google.com \
  ghcr.io/myorg/myimage:v1.0

Fulcio: Certificate Authority

Fulcio is a free certificate authority that issues short-lived signing certificates based on OIDC identity tokens. When a developer signs with Cosign, Fulcio verifies their identity through an OIDC provider and issues a certificate that's valid for approximately 20 minutes.

Because the certificates are short-lived, there's no key to compromise or revoke. The signing identity is the developer's verified email address, tied to their existing identity provider. This eliminates the key management problem entirely.

Rekor: Transparency Log

Rekor is an immutable, tamper-evident transparency log (similar in concept to Certificate Transparency logs for TLS certificates). Every signature created through Sigstore is recorded in Rekor.

This provides several critical properties:

• Discoverability — Anyone can search for signatures on a given artifact
• Tamper evidence — Entries cannot be removed or modified without detection
• Temporal proof — The log proves that a signature existed at a specific time, which is essential for short-lived certificate verification

When verifying a signature, Cosign checks Rekor to confirm that the signing event was logged during the certificate's validity period. This is how keyless signing remains secure — even though the certificate has expired by verification time, the Rekor entry proves the signature was created while the certificate was valid.

Why This Matters for Supply Chain Security

Solving the SolarWinds Problem

The SolarWinds attack succeeded partly because there was no independent way to verify that the distributed binary matched the intended build output. If SolarWinds had signed their artifacts with provenance attestations recorded in a transparency log, the mismatch between the clean source code and the trojanized binary could have been detected.

Container Image Integrity

Docker images pulled from registries are not verified by default. Docker Content Trust (Notary) exists but is rarely used due to complexity. Cosign makes container signing practical:

# In CI: sign after building
cosign sign --yes $IMAGE_DIGEST

# In Kubernetes: verify before deploying (using policy controllers)
# Kyverno and OPA Gatekeeper both support Cosign verification

Build Provenance

Sigstore isn't just for signing — it's for attesting. Cosign supports attaching attestations to artifacts, including:

• SLSA build provenance (what system built this, from what source)
• Vulnerability scan results
• SBOM data
• Custom policy attestations

This creates a verifiable chain from source code to deployed artifact.

Adoption in 2021

Sigstore's adoption accelerated throughout 2021:

• npm announced plans to adopt Sigstore for package signing
• PyPI began exploring Sigstore integration
• Kubernetes adopted Sigstore for signing release artifacts
• GitHub Actions added support for SLSA provenance generation using Sigstore
• Distroless container images from Google are signed with Cosign

The ecosystem is converging on Sigstore as the standard for software signing. Unlike PGP — which has been available for 30 years and is still rarely used in practice — Sigstore's keyless model has a realistic path to widespread adoption.

Getting Started

1. Install Cosign: go install github.com/sigstore/cosign/cmd/cosign@latest or download a binary from the releases page

2. Sign your container images in CI: Add a Cosign signing step after your image build. Most CI platforms support OIDC token generation for keyless signing.

3. Verify before deploying: Use Kubernetes admission controllers (Kyverno, OPA Gatekeeper) to enforce signature verification.

4. Attach attestations: Include SBOM and provenance attestations alongside signatures to provide complete supply chain transparency.

5. Verify in your pipeline: Add cosign verify steps when pulling third-party images.

How Safeguard.sh Helps

Safeguard.sh integrates with the Sigstore ecosystem to provide end-to-end supply chain verification. The platform verifies Cosign signatures on container images and other artifacts, ensuring that only signed and verified components enter your deployment pipeline.

Beyond signature verification, Safeguard.sh correlates signing identities with your expected publisher list. If a container image is signed but by an unexpected identity, or if a previously signed image appears unsigned, the platform flags the discrepancy. This catches scenarios where legitimate signing infrastructure is compromised or bypassed.

The platform also complements Sigstore's signing capabilities with comprehensive SBOM data. While Cosign proves who built an artifact and that it wasn't tampered with, Safeguard.sh tells you what's inside that artifact and whether it contains known vulnerabilities. Together, they provide the complete transparency chain — from source to content to deployment — that modern supply chain security demands.