TL;DR, What is Cosign?
Cosign is a command-line tool for signing and verifying software artifacts.
Traditional code signing often adds a lot of operational work and security risk because of complex key management. Cosign solves this problem by offering “keyless signing” using short-lived certificates from Sigstore's certificate authority, Fulcio. The tool uses OpenID Connect (OIDC) identities to prove who you are and stores signatures in a public, tamper-proof transparency log called Rekor. As a result, you get strong guarantees of artifact integrity and origin. The keyless approach secures your CI/CD pipelines without the hassle of managing long-term private keys.
Developed within the open-source Sigstore project, Cosign helps improve software supply chain security.
Software Supply Chain Security [Cheat Sheet]
Learn how to secure the software supply chain end-to-end – from managing third-party dependencies and open-source libraries to protecting build pipelines.

At-A-Glance
GitHub: https://github.com/sigstore/cosign
License: Apache-2.0
Primary Language: Go
Stars: 5.3k ⭐
Last Release: v2.6.0 on September 12, 2025
Topics/Tags: container-signing, security, oci, software-supply-chain-security
Common use cases
1. Automated CI/CD pipeline signing: Cosign integrates into build pipelines to automatically sign container images after successful builds. Using CI service accounts, the tool provides cryptographic proof that an artifact came from a trusted, automated process and has not been altered.
2. Software supply chain attestation: You can attach important metadata like SBOMs and vulnerability scan results to software as signed attestations. Your downstream consumers then get verifiable information about an artifact's security posture, helping them make smart deployment decisions based on trusted data.
3. Verification of open-source dependencies: Cosign enables you to verify the integrity of container images and OCI artifacts, including open-source projects that publish signed releases. When maintainers sign their releases, you can programmatically verify these signatures before use. Doing so helps reduce risks from compromised or maliciously changed third-party code.
4. Enforcing secure deployment policies: The tool works with Kubernetes admission controllers to enforce security gates at runtime. You can set policies that require container images to have a valid signature from a trusted builder or have specific attestations before they can run in a cluster.
5. Meeting regulatory and compliance mandates: Cosign provides the cryptographic evidence and tamper-evident audit trails that support compliance with frameworks like SLSA and SSDF. With verifiable signatures and a public transparency log, organizations can prove software integrity and provenance to auditors and regulators.
How does Cosign work?
Cosign makes software signing easier with a “keyless” workflow using the Sigstore ecosystem. When you sign something, Cosign creates a temporary key pair and uses an OIDC provider like Google or GitHub to confirm your identity. The tool then asks Fulcio for a short-lived certificate that connects the key to your verified identity. Next, Cosign stores the signature in an OCI registry and creates an entry in the Rekor transparency log. The result is a verifiable, timestamped record of the signing event. The whole process removes the need for you to manage long-term private keys.
Key operations include:
Certificate issuance (Fulcio): The Fulcio certificate authority issues short-lived X.509 certificates, usually valid for a few minutes (usually 10 minutes). These certificates cryptographically link a temporary public key to a verified OIDC identity.
Transparency logging (Rekor): All signing events, including the signature and certificate, get submitted to Rekor’s unchangeable, tamper-proof log. Rekor's log provides a public audit trail for all signed artifacts.
Verification: To verify a signature, Cosign checks it against the artifact, validates the certificate chain back to Fulcio’s root, and confirms a matching entry exists in the Rekor transparency log.
Core Capabilities:
1. Keyless signing and identity-based security: Cosign removes the burden of long-term key management by using OIDC providers for authentication. Fulcio issues short-lived certificates tied to a user or service identity, which you then use to sign artifacts. The keyless method improves security by linking signatures directly to a verified identity and recording them in Rekor’s public transparency log for auditing.
2. Comprehensive artifact signing and verification: You can natively sign a wide range of software artifacts, including OCI container images, WebAssembly modules, SBOMs, and arbitrary blobs or binary files. Cosign stores signatures as separate OCI artifacts in the same registry, which fits smoothly into existing container workflows. You don't need separate infrastructure for signature storage.
3. Flexible key management integration: Cosign provides several signing options beyond its main keyless mode to fit different security policies. The tool integrates with existing enterprise tools, including hardware security modules (HSMs), cloud KMS from providers like AWS, Google, and Azure, and secrets management solutions like HashiCorp Vault. Organizations can adopt Cosign while using their current investments in secure key storage.
4. Immutable transparency and auditability: Cosign improves supply chain integrity by automatically recording every signing event to the Rekor transparency log. The append-only, publicly verifiable ledger gives you an unchangeable, timestamped record of when an artifact was signed and by whom. The log enables continuous monitoring, allowing teams to spot unauthorized signing activity and provide strong evidence for compliance.
5. Rich attestations and policy enforcement: The tool moves beyond simple signatures by supporting in-toto attestations. These attestations let you cryptographically link rich metadata—like vulnerability scan reports, build environment details, or SBOMs—directly to an artifact. When paired with Kubernetes admission controllers like Gatekeeper or OPA, attestations enable detailed policy enforcement, ensuring only artifacts that meet specific security criteria get deployed.
Limitations
1. Reliance on public infrastructure: The default keyless signing mode depends on public Sigstore services like Fulcio and Rekor being available. Any outage or connection issue with this central infrastructure can disrupt signing and verification workflows for everyone.
2. Ecosystem adoption dependency: For end-to-end verification, Cosign's effectiveness depends on broad adoption across the software supply chain. Your chain of trust is incomplete if upstream software suppliers and open-source projects do not sign their artifacts.
3. Initial learning curve: Understanding how Cosign, OIDC, Fulcio, Rekor, and in-toto attestations work together can be a challenge for teams new to software supply chain security concepts.
4. Challenges in air-gapped environments: The main keyless workflow needs internet access, which makes it hard to use in fully air-gapped or network-restricted environments. Setting up private instances of the whole Sigstore stack is possible but adds a lot of operational work.
5. Shifts security burden to identity provider: The keyless model moves the main security responsibility from managing crypto keys to securing your OIDC identity provider (like GitHub or Google). An attacker who compromises an identity account can create valid signatures.
Cosign guarantees that your container image or artifact is signed and hasn’t been tampered with. To go beyond integrity, you can pair Cosign’s verified artifacts with a security posture tool like Wiz that analyzes vulnerabilities and misconfigurations at runtime. This combination helps you identify which verified artifacts are actually safe to deploy in your cloud.
Getting Started:
Step 1: Install Go 1.22+ if it's not already on your system (if you are building from the source).
Step 2: Clone the Cosign repository:
git clone https://github.com/sigstore/cosign
Step 3: Change into the project directory:
cd cosign
Step 4: Build and install Cosign using Go:
go install ./cmd/cosign@latest
Step 5: Run Cosign to check the installation:
cosign version
You are now ready to start signing and verifying container images with Cosign!
FAQ
Alternatives
Feature | Cosign | Notation | Docker Content Trust |
---|---|---|---|
Signing Approach | Keyless signing via OIDC and ephemeral certificates (Fulcio)Also supports traditional PKI, hardware tokens, and cloud KMS | Relies on traditional X.509 PKI certificate-based signingRequires users to acquire and manage their own certificates from a trusted CA | Based on Notary v1, which leverages TUF concepts for trust metadata and key delegation |
Artifact Support | Signs any OCI artifact, including container images, SBOMs, attestations, and arbitrary blobs | Primarily focused on OCI container images and other OCI artifactsSignatures are stored as OCI artifacts | Focused exclusively on Docker container images |
Transparency Log | Integrates natively with the Rekor transparency log, providing a public, immutable record of signing events for auditability | Does not have a built-in public transparency logTrust is established through the certificate chain of the signing key | No public transparency logTrust is managed within the Notary server's TUF metadata |
Attestation Format | Strong support for in-toto attestations, enabling rich, verifiable claims about the software supply chain (e.g., vulnerability scans, build provenance) | Supports attestations, but the ecosystem and tooling for rich, policy-enforceable attestations are less mature compared to Cosign | No support for attestations; focused solely on signing the image itself |
Key Management | Flexible: Keyless (no long-term keys to manage), or integration with major cloud KMS providers (AWS, GCP, Azure), HashiCorp Vault, and hardware tokens | Requires manual key and certificate managementIntegrates with cloud KMS providers for private key storage | Complex key management with multiple roles (root, targets, snapshot, timestamp) as defined by the TUF specification |
Registry Storage | Stores signatures as separate OCI artifacts in the registry, linked to the manifest by a tag naming convention (.sig ) | Follows the OCI reference types specification to link signatures to the artifacts they sign, providing a more standardized approach | Requires a separate Notary server to store and manage trust data (TUF metadata)Not stored directly in the OCI registry |
Maintenance Status | Actively developed and maintained by the Sigstore community, part of the Linux FoundationStrong industry adoption | Actively developed as a CNCF project, positioned as the successor to Notary V1 | Deprecated and being retiredDocker is transitioning away from it, and it is no longer actively maintained |