Sigstore for Enterprise Software Supply Chain Integrity

Overview

Sigstore is an open-source software supply chain security stack designed to make artifact signing and verification practical at scale. Its core purpose is to let organizations prove who built an artifact, what was signed, and when it was recorded in a transparency log.

Enterprises adopt Sigstore to address risks highlighted by modern supply chain attacks: tampered container images, compromised build runners, and unsigned release artifacts. Instead of relying only on long-lived private keys, Sigstore supports keyless signing using OpenID Connect (OIDC) identities and short-lived certificates. This reduces operational overhead and limits blast radius if a build environment is compromised.

Common enterprise use cases include:

• Signing container images in CI/CD
• Verifying artifacts in Kubernetes admission control
• Attesting SBOMs and SLSA provenance
• Enforcing release integrity for internal packages and binaries

Architecture

Sigstore consists of several core components:

• Cosign: CLI and library for signing and verifying container images and blobs
• Fulcio: Certificate authority issuing short-lived signing certificates tied to OIDC identity
• Rekor: Transparency log storing signed metadata and proof of inclusion
• Policy Controller: Kubernetes admission control for signature verification policies

Deployment models

1. Public Sigstore service: Fastest adoption path, suitable for internet-connected workloads
2. Private/self-managed Sigstore: Preferred for regulated environments, sovereign cloud, or restricted identities
3. Hybrid model: Public signing for open-source releases, private verification and policy enforcement internally

Data flow

1. CI workload authenticates to OIDC provider such as GitHub Actions, Azure AD, or Google Workload Identity.
2. Cosign requests a short-lived certificate from Fulcio.
3. Artifact digest is signed with an ephemeral key.
4. Signature and certificate are logged in Rekor.
5. Deploy-time controls verify signature, certificate identity, and Rekor inclusion proof.

Implementation Guide

1. Install Cosign

curl -O -L https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64
sudo install -m 0755 cosign-linux-amd64 /usr/local/bin/cosign
cosign version

2. Authenticate to container registry

echo "$REGISTRY_PASSWORD" | docker login registry.example.com -u cicd-bot --password-stdin

3. Build and push image

docker build -t registry.example.com/payments/api:1.4.2 .
docker push registry.example.com/payments/api:1.4.2

4. Keyless sign with OIDC

export COSIGN_EXPERIMENTAL=1
cosign sign registry.example.com/payments/api:1.4.2

5. Verify signature and identity

cosign verify registry.example.com/payments/api:1.4.2 \
  --certificate-identity "https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

6. Generate and attach an SBOM attestation

syft registry.example.com/payments/api:1.4.2 -o spdx-json > sbom.json
cosign attest --predicate sbom.json --type spdxjson registry.example.com/payments/api:1.4.2

7. Enforce verification in Kubernetes

Create a ClusterImagePolicy for Sigstore Policy Controller:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: payments-images
spec:
  images:
  - glob: "registry.example.com/payments/**"
  authorities:
  - keyless:
      identities:
      - issuer: "https://token.actions.githubusercontent.com"
        subject: "https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main"

Code Examples

Example 1: Sign a container image

export COSIGN_EXPERIMENTAL=1
cosign sign --yes registry.example.com/platform/web:2.3.1

Example 2: Kubernetes policy enforcement

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: platform-policy
spec:
  images:
  - glob: "registry.example.com/platform/*"
  authorities:
  - keyless:
      url: "https://fulcio.sigstore.dev"
      identities:
      - issuer: "https://token.actions.githubusercontent.com"
        subjectRegExp: "https://github.com/acme/.+/.github/workflows/.+"

Example 3: Verify a blob and Rekor entry in Python

import subprocess
artifact = "release.tar.gz"
signature = "release.tar.gz.sig"
certificate = "release.tar.gz.pem"
cmd = ["cosign", "verify-blob", "--signature", signature, "--certificate", certificate, artifact]
result = subprocess.run(cmd, capture_output=True, text=True)
print(result.stdout)
if result.returncode != 0:
    raise SystemExit(result.stderr)

Security Hardening

• Prefer keyless signing with short-lived certificates over static keys where possible.
• If using key pairs, store private keys in HSM, KMS, or Vault and require MFA-backed operator access.
• Restrict CI signing identities to dedicated release workflows; do not allow all branches to sign production artifacts.
• Enforce immutable tags and verify by digest in deployment manifests.
• Mirror Rekor data or run private transparency infrastructure for high-assurance and air-gapped validation scenarios.
• Log all signing and verification events to SIEM for correlation with pipeline and registry activity.

Comparison

Troubleshooting

1. OIDC token retrieval failure

Log sample:

Error: signing [registry.example.com/payments/api:1.4.2]: getting OIDC token: oauth2: cannot fetch token: 401 Unauthorized

Fix: Confirm the CI runner has id-token: write permissions and outbound access to the OIDC issuer.

2. Rekor upload timeout

Log sample:

error during command execution: Post "https://rekor.sigstore.dev/api/v1/log/entries": context deadline exceeded

Fix: Check proxy egress rules, TLS inspection behavior, and retry with COSIGN_TIMEOUT=300s for constrained networks.

3. Identity mismatch during verification

Log sample:

Error: no matching claims: expected issuer https://token.actions.githubusercontent.com, subject https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main

Fix: Verify the exact workflow path, branch ref, and issuer configured in the verification policy.

Best Practices

Do

• Bind signatures to workload identity: Example: only release.yml on main can sign production images.
• Verify before deploy: Enforce admission policies in Kubernetes, not just CI checks.
• Attach attestations: Store SBOM and provenance alongside signatures for auditability.
• Use digest pinning: Deploy image@sha256:... instead of mutable tags.

Don't

• Don't share static signing keys across teams or repositories.
• Don't trust signatures without validating issuer, subject, and transparency log inclusion.
• Don't allow feature branches to sign artifacts destined for production.
• Don't treat signing as a replacement for scanning; combine Sigstore with vulnerability and policy controls.