Sigstore and Cosign

Sigstore is an open-source project (Linux Foundation) that provides free code signing infrastructure based on identity rather than long-lived keys. Instead of managing a signing key (generating, storing in HSM, rotating, protecting from compromise), you authenticate with your identity (GitHub, Google, Microsoft OIDC), receive a short-lived certificate (valid for ~10 minutes), sign your artifact, and the signing event is recorded in a public transparency log (Rekor). The certificate expires immediately after — there’s no key to steal, rotate, or manage.

Why it matters

• No key management — the #1 barrier to code signing adoption is key management complexity (HSMs, rotation, access control). Sigstore eliminates it entirely. Sign with your identity, not a key.
• Identity-based trust — instead of “this artifact was signed by key X” (who has key X?), it’s “this artifact was signed by user@example.com via GitHub Actions” — directly attributable to a verified identity.
• Transparency log — every signature is recorded in Rekor (append-only, publicly auditable). If someone signs something they shouldn’t, it’s visible. If a signature is forged, it won’t appear in the log.
• Container-native — cosign stores signatures in OCI registries alongside container images. No separate signature files, no separate distribution channel. docker pull + cosign verify is the complete workflow.
• Free and open — Sigstore’s public infrastructure (Fulcio CA, Rekor log, cosign tool) is free to use. No certificate purchases, no vendor contracts.

How it works

Sigstore components:

1. Fulcio (Certificate Authority) — issues short-lived signing certificates (~10 min validity) based on OIDC identity verification. No CSR needed — just prove your identity.
2. Rekor (Transparency Log) — append-only log recording all signing events. Provides inclusion proofs (prove a signature was logged) and consistency proofs (prove the log hasn’t been tampered with).
3. Cosign (Signing Tool) — CLI tool for signing and verifying container images, blobs, and attestations. Handles the Fulcio/Rekor interaction automatically.

Keyless signing flow:

1. User runs cosign sign on a container image
2. Cosign initiates OIDC authentication (browser opens, user logs in with GitHub/Google/etc.)
3. Cosign sends the OIDC token to Fulcio
4. Fulcio verifies the token, issues a short-lived certificate binding the user’s identity to an ephemeral key pair
5. Cosign signs the image digest with the ephemeral private key
6. Cosign uploads the signature + certificate to Rekor (transparency log entry created)
7. Cosign stores the signature in the OCI registry alongside the image
8. Ephemeral private key is discarded — it existed only for this signing operation

In real systems

Cosign — sign a container image (keyless):

# Sign (opens browser for OIDC auth, or uses ambient credentials in CI)
cosign sign ghcr.io/myorg/myapp@sha256:abc123...

# In GitHub Actions (automatic OIDC, no browser needed):
- uses: sigstore/cosign-installer@v3
- run: cosign sign ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}
  env:
    COSIGN_EXPERIMENTAL: 1  # Enable keyless signing

Cosign — verify a container image:

# Verify signature and check identity
cosign verify ghcr.io/myorg/myapp@sha256:abc123... \
  --certificate-identity="https://github.com/myorg/myapp/.github/workflows/release.yml@refs/tags/v1.0" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

# Output: Verified OK
# Proves: this image was signed by the specified GitHub Actions workflow

Kubernetes policy enforcement (Kyverno + cosign):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-cosign-signature
    match:
      resources:
        kinds: ["Pod"]
    verifyImages:
    - imageReferences: ["ghcr.io/myorg/*"]
      attestors:
      - entries:
        - keyless:
            issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/myorg/*"

Only images signed by the organization’s GitHub Actions workflows can be deployed to the cluster.

Signing with a key (non-keyless, for air-gapped environments):

# Generate a cosign key pair (when keyless isn't possible)
cosign generate-key-pair

# Sign with key
cosign sign --key cosign.key ghcr.io/myorg/myapp@sha256:abc123...

# Verify with public key
cosign verify --key cosign.pub ghcr.io/myorg/myapp@sha256:abc123...

Where it breaks

OIDC provider outage — keyless signing depends on the OIDC provider (GitHub, Google) being available for authentication, and Fulcio being available to issue certificates. If either is down, signing fails. For critical release pipelines, have a fallback: a traditional key-based signing path (cosign supports both) that doesn’t depend on external services.

Identity scope too broad — verification policy checks that the signer is “anyone from github.com/myorg.” An attacker who compromises any repository in the organization can sign malicious images that pass verification. Narrow the identity scope: verify the specific workflow file path and branch (refs/tags/* only), not just the organization.

Rekor log availability for verification — verification checks that the signature appears in Rekor. If Rekor is unreachable during verification (network issue, outage), verification fails even though the signature is valid. For offline or air-gapped verification, cosign supports bundled proofs (the Rekor inclusion proof is stored alongside the signature) so verification doesn’t require live Rekor access.

Operational insight

Sigstore’s keyless model fundamentally changes the threat model for code signing. Traditional signing: the threat is key compromise (attacker steals the signing key and signs malware). Keyless signing: the threat is identity compromise (attacker compromises the OIDC identity — GitHub account, CI pipeline — and signs malware with a legitimate identity). The attack surface shifts from “protect a long-lived key” to “protect identity provider accounts and CI/CD pipeline integrity.” This means MFA on all developer accounts, strict branch protection, and pipeline security become the critical controls — not HSM management. The security problem doesn’t disappear; it moves to a different (arguably more manageable) layer.

Related topics

• What is Code Signing
• Software Supply Chain Security
• Code Signing in CI/CD Pipelines
• What is Certificate Transparency
• Digital Signatures