Cosign

The primary use case. Cosign signs container images stored in OCI-compliant registries. It generates a signature that is stored alongside the image, allowing a verifier to confirm the image has not been altered since build time.

• Keyless signing binds the image to a build system's OIDC identity (e.g., a GitHub Actions workflow).
• Verification checks the signature against the Rekor transparency log and the signer's identity.
• Example: cosign sign --yes ghcr.io/org/app:v1.2.3

Cosign can generate and sign an in-toto attestation that contains an SBOM, cryptographically binding a list of dependencies to a specific artifact. This proves the SBOM was produced by a trusted build process and hasn't been tampered with.

• Attestation types include SPDX, CycloneDX, and custom predicates.
• Verification policy can reject artifacts without a valid, signed SBOM from a specific identity.
• Command: cosign attest --predicate sbom.spdx.json --type spdx <image>

Beyond containers, Cosign signs arbitrary binary blobs, release assets, and configuration files. This is critical for securing software distribution channels where artifacts are downloaded directly.

• Detached signatures are stored as separate .sig files, leaving the original blob unmodified.
• Bundle mode wraps the original blob and signature into a single distributable file.
• Use case: Signing compiled binaries, tarballs, or policy documents before uploading to a release page.

Integrate Cosign verification directly into the Kubernetes admission chain using tools like Kyverno or Sigstore Policy Controller. This enforces that only signed images from trusted identities can be deployed to a cluster.

• Policy as Code: Define a ClusterImagePolicy that requires a valid Cosign signature from [email protected].
• Enforcement point: The API server rejects unsigned or improperly attested pods before they are persisted to etcd.
• Prevents accidental deployment of development builds into production namespaces.

Cosign's keyless mode is purpose-built for CI/CD environments. It uses the pipeline's own identity token to sign artifacts, eliminating the need to inject and rotate long-lived secrets.

• GitHub Actions: The id-token: write permission allows the workflow to request an OIDC token, which Cosign uses to obtain a short-lived Fulcio certificate.
• GitLab CI: Similarly leverages the built-in CI_JOB_JWT_V2 token.
• Result: Every build artifact is immutably linked to the exact pipeline run, commit SHA, and repository that produced it.

Cosign can sign and verify Git commits and tags directly, establishing a cryptographic link between source code and the resulting artifact. This closes the loop on supply chain integrity from source to deployment.

• Sign a commit: cosign sign-blob --oidc-issuer https://token.actions.githubusercontent.com --yes commit-sha.txt
• Verify: Confirm the commit was signed by the expected repository's CI pipeline.
• This provides a verifiable chain of custody from the developer's intent to the running binary.

The open-source parent project of Cosign that provides the public good infrastructure for keyless signing. Sigstore issues short-lived, ephemeral certificates tied to OpenID Connect identities, eliminating the need for developers to manage long-lived private keys. The ecosystem includes:

• Fulcio: The certificate authority issuing signing certificates after OIDC authentication.
• Rekor: The transparency log providing an immutable, append-only record of signing events.
• Cosign: The client-side tool for signing and verifying artifacts.

Supply-chain Levels for Software Artifacts (SLSA, pronounced 'salsa') is a graduated security framework that defines controls to prevent tampering across the build pipeline. Cosign directly supports SLSA Level 2 and 3 requirements by providing:

• Provenance attestation: Cryptographically verifiable metadata about how and where an artifact was built.
• Non-falsifiable provenance: Attestations signed with short-lived certificates tied to a specific build identity.
• Hermetic build verification: Ensuring builds are isolated from external influence.

A framework that cryptographically attests to the integrity of every step in a software supply chain. While Cosign signs the final artifact, In-toto creates a verifiable chain of custody across the entire pipeline. The two tools complement each other:

• In-toto defines the layout of expected steps and functionaries.
• Cosign signs the resulting link metadata and final artifacts.
• Together they provide end-to-end, tamper-evident provenance from source commit to deployed binary.

A deploy-time enforcement mechanism that requires valid cryptographic signatures before a container image can be deployed to production. Cosign integrates with platforms like:

• Kubernetes admission controllers: Using tools like Kyverno or OPA Gatekeeper to verify Cosign signatures at pod creation time.
• Google Cloud Binary Authorization: Enforcing policies that only allow images signed by trusted identities.
• Sigstore Policy Controller: A Kubernetes-native admission controller that verifies Cosign signatures against configurable policies.

An append-only, cryptographically verifiable ledger that records every signing event. When Cosign performs a keyless signing, the signature and certificate are published to Rekor, providing:

• Auditability: Anyone can verify when and by whom an artifact was signed.
• Detectability: Compromised keys or unauthorized signings become immediately visible.
• Non-repudiation: Signers cannot later deny having signed an artifact.
• Monitoring: Organizations can set up alerting on unexpected signing events for their namespace.