Sign and Verify Artifacts with Sigstore cosign

By Khimananda Oli | Last reviewed: August 2026

Supply chain attacks have shifted from compromising source code to targeting the build and distribution process itself. If you cannot cryptographically prove an artifact’s origin and integrity, your deployment pipeline remains vulnerable to tampering regardless of how secure your application logic is. Learning to sign and verify artifacts with Sigstore cosign establishes a verifiable chain of custody that satisfies both security best practices and modern compliance frameworks like SOC 2.

How does keyless signing work when you sign and verify artifacts with Sigstore cosign?

Traditional code signing requires managing long-lived PGP or X.509 private keys, creating operational overhead and significant risk if those keys are leaked. Sigstore eliminates this friction through keyless signing, which leverages short-lived certificates issued by Fulcio based on your OIDC identity (GitHub Actions, Google Cloud, etc.). When you sign an artifact, cosign requests a certificate from Fulcio, signs the artifact digest, and records the signature in the Rekor transparency log. This creates an auditable, tamper-evident record that anyone can independently verify without needing access to your private infrastructure.

This architecture means verification checks three things simultaneously: the cryptographic signature matches the artifact digest, the certificate was issued by a trusted Fulcio instance at signing time, and the signature exists in the public transparency log. For teams implementing CI/CD best practices, this provides automated, non-repudiable proof of build provenance without adding secret management complexity.

How do you configure GitHub Actions to sign container images automatically?

Automating signature generation in your CI pipeline ensures every production artifact is signed consistently. GitHub Actions integrates natively with Sigstore’s keyless flow because the workflow token serves as the OIDC credential. You must grant the id-token: write permission to allow the runner to request Fulcio certificates.

Complete workflow example for automated signing

name: Build and Sign Container
on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write # Required for keyless signing

jobs:
  build-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install cosign
        uses: sigstore/cosign-installer@v3
        
      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
          
      - name: Build and Push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          
      - name: Sign and Verify Artifacts with Sigstore cosign
        env:
          DIGEST: ${{ steps.build.outputs.digest }}
        run: |
          cosign sign --yes \
            --rekor-url "https://rekor.sigstore.dev" \
            "ghcr.io/${{ github.repository }}@${DIGEST}"
            
      - name: Verify Signature Immediately
        env:
          DIGEST: ${{ steps.build.outputs.digest }}
        run: |
          cosign verify \
            --certificate-identity-regexp="https://github.com/${{ github.repository }}/.*" \
            --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
            "ghcr.io/${{ github.repository }}@${DIGEST}"

The --yes flag skips interactive confirmation prompts in CI environments. Always verify immediately after signing within the same job; this catches configuration errors before they propagate to downstream consumers. Note that we reference images by digest (@sha256:...) rather than tag, since tags are mutable and defeat the purpose of cryptographic binding.

What commands do you use to sign and verify artifacts with Sigstore cosign locally?

While automation handles production flows, local signing remains necessary for ad-hoc releases, debugging, or signing non-container artifacts like SBOMs and binary executables. The local keyless flow opens a browser for OIDC authentication, making it unsuitable for unattended scripts but perfectly appropriate for developer workstations.

1. Install cosign: Download the latest release from the official Sigstore GitHub repository or use brew install cosign on macOS. Verify installation with cosign version.
2. Sign a container image: Run cosign sign ghcr.io/your-org/app@sha256:abc123.... Your browser opens for OIDC login. After authentication, cosign generates an ephemeral keypair, obtains a Fulcio certificate, signs the digest, and uploads the signature to the registry as a separate artifact tagged with the digest suffix.
3. Sign arbitrary files: Use cosign sign-blob --output-signature file.sig --output-certificate cert.pem ./artifact.tar.gz. This produces detached signature and certificate files suitable for distribution alongside binaries or documents.
4. Verify container signatures: Execute cosign verify --certificate-identity="[email protected]" --certificate-oidc-issuer="https://accounts.google.com" ghcr.io/your-org/app@sha256:abc123.... Verification fails if the identity or issuer doesn't match exactly.
5. Verify blob signatures: Run cosign verify-blob --signature file.sig --certificate cert.pem --certificate-identity="[email protected]" --certificate-oidc-issuer="https://accounts.google.com" ./artifact.tar.gz.

A common mistake is attempting to verify using only the image reference without specifying certificate identity and OIDC issuer. Without these parameters, cosign accepts any valid Sigstore signature, which provides integrity but no meaningful provenance guarantees. Always pin to specific identities in production verification policies.

How do you enforce signature verification policies in Kubernetes admission control?

Signing artifacts provides no security benefit unless verification is enforced at deployment time. In Kubernetes environments, admission controllers reject unsigned or improperly signed images before they reach cluster nodes. This transforms cryptographic signatures from optional metadata into mandatory gatekeeping.

Kyverno and OPA Gatekeeper are the two dominant policy engines for this purpose. Kyverno offers native cosign integration with simpler YAML syntax, while OPA provides Rego-based flexibility for complex organizational rules. Both query Rekor and fetch registry signatures synchronously during admission review.

For most teams adopting artifact signing in 2026, Kyverno provides the fastest path to enforcement. A minimal ClusterPolicy verifying GitHub Actions-signed images requires fewer than 30 lines of YAML and integrates cleanly with GitOps workflows managed by ArgoCD. Reserve OPA for environments where signature verification intersects with broader compliance policies already expressed in Rego.

What are the operational trade-offs between keyless and key-based signing?

Keyless signing dominates greenfield deployments, but key-based signing remains relevant for specific scenarios. Understanding when each approach applies prevents architectural missteps as your organization matures.

Keyless signing assumes reliable OIDC provider availability. If your build environment operates in an air-gapped network or depends on an internal IdP with frequent outages, key-based signing with securely stored keys (ideally in HashiCorp Vault or AWS KMS) becomes necessary. Teams managing secrets with HashiCorp Vault can integrate Vault’s transit engine as a cosign KMS provider, gaining hardware-backed key protection while retaining programmatic signing capabilities.

Another consideration is identity stability. Keyless certificates bind to OIDC subjects that may change when developers leave or service accounts rotate. Key-based signatures maintain consistent identity regardless of personnel changes, which matters for long-lived artifacts or regulatory contexts requiring multi-year attribution. Most organizations adopt a hybrid model: keyless for CI-generated ephemeral artifacts, key-based for release binaries and compliance-sensitive deliverables.

Next Steps for Securing Your Software Supply Chain

Implementing the ability to sign and verify artifacts with Sigstore cosign addresses one critical layer of supply chain security, but it should not exist in isolation. Pair signature enforcement with SBOM generation, dependency scanning, and least-privilege IAM policies to create defense-in-depth. Start by enabling keyless signing in your primary CI pipeline this week, then add admission controller enforcement within the next sprint. Audit your current artifact provenance gaps and prioritize signing for any image deployed to production or shared with external customers. If your team needs guidance designing a compliant, automated signing workflow tailored to your infrastructure, reach out to discuss your specific requirements.