Container image signing should be straightforward: someone builds an image, signs it, and consumers verify the signature before running it. In practice, the container signing ecosystem has been fragmented for years, with competing standards, incompatible tooling, and incomplete implementations.
The good news is that the ecosystem is converging around OCI-native signing standards. The bad news is that most teams still have no image signing in place, and the ones that do are often using deprecated approaches.
Why Container Image Signing Matters
A container image is an opaque blob of bytes. When you pull nginx:latest from a registry, you are trusting that the image was built by the nginx maintainers, has not been tampered with in transit or at rest, and contains what you expect. Without signing and verification, you have no cryptographic proof of any of these properties.
Docker Content Trust, based on Notary v1 and The Update Framework (TUF), was the first widely available signing solution for containers. It provides signature verification at pull time and prevents running unsigned images. However, it has significant limitations: it is Docker-specific, requires a separate Notary server, and has seen minimal adoption outside of Docker Enterprise environments.
The OCI Signing Landscape
Sigstore and Cosign
Sigstore is an open-source project that provides keyless signing for software artifacts, including container images. Cosign is Sigstore's tool for signing and verifying container images and other OCI artifacts.
Cosign's key innovation is keyless signing using OIDC identity. Instead of managing GPG keys or X.509 certificates, developers authenticate with their identity provider (GitHub, Google, Microsoft), and Sigstore issues a short-lived certificate tied to that identity. The signature and certificate are stored in a transparency log (Rekor) that provides a public, tamper-evident record of all signing events.
# Sign an image with keyless signing
cosign sign myregistry.com/myimage:v1.0
# Verify an image
cosign verify myregistry.com/myimage:v1.0 \
--certificate-identity user@example.com \
--certificate-oidc-issuer https://accounts.google.com
This approach eliminates key management entirely. There are no private keys to protect, no key rotation to manage, and no key distribution to coordinate. The tradeoff is a dependency on Sigstore's infrastructure (Fulcio CA and Rekor transparency log) and your OIDC provider.
Notary v2 (Notation)
Notary v2, now called Notation, is the OCI-native successor to Docker Content Trust. It uses the OCI distribution spec's referrers API to attach signatures directly to images in the registry, without requiring a separate signature server.
Notation uses X.509 certificates for signing, which aligns with enterprise PKI infrastructure. Organizations that already manage certificate hierarchies can extend them to cover container signing.
# Sign with Notation
notation sign myregistry.com/myimage@sha256:abc123
# Verify
notation verify myregistry.com/myimage@sha256:abc123
Notation is backed by Microsoft, AWS, and the Notary project. It is designed for enterprise environments where centralized key management and certificate-based identity are requirements.
OCI Image Signatures Spec
The OCI is standardizing how signatures attach to images through the reference types specification. This spec defines how signatures, attestations, and other metadata associate with an OCI artifact in a registry.
Both Cosign and Notation can store signatures using OCI reference types, which means registries that support the spec can store and serve signatures from either tool. This is the interoperability layer that the ecosystem has been missing.
Choosing a Signing Approach
Keyless (Sigstore/Cosign)
Choose Sigstore keyless signing when your team uses GitHub, Google, or Microsoft identity providers, you want to minimize key management overhead, public transparency of signing events is acceptable, and your registry supports OCI artifacts.
Keyless signing is ideal for open-source projects and organizations that want to get started with signing quickly. The Sigstore public goods infrastructure handles the complexity.
Key-Based (Cosign with Keys)
Cosign also supports traditional key-based signing for environments where keyless is not appropriate:
cosign generate-key-pair
cosign sign --key cosign.key myregistry.com/myimage:v1.0
This gives you Cosign's UX without depending on Sigstore's public infrastructure. You manage the keys yourself.
Certificate-Based (Notation)
Choose Notation when your organization has existing PKI infrastructure, you need to comply with regulations that require specific certificate standards, you want enterprise-grade key management with HSM support, or you are running Azure Container Registry or AWS ECR which have native Notation integration.
Implementation Steps
Step 1: Start With Verification
Before requiring signing, implement verification-only mode. Pull signatures for your existing images and see what your current state looks like. Many popular base images are already signed with Cosign.
Step 2: Sign in CI/CD
Integrate signing into your CI/CD pipeline immediately after image push. Cosign with keyless signing requires minimal setup in GitHub Actions, GitLab CI, or similar platforms that provide OIDC tokens.
Step 3: Enforce Verification
Once signing is in place, enforce verification at deployment time. Kubernetes admission controllers like Sigstore's Policy Controller or Kyverno can block unsigned images from running in your cluster.
Step 4: Add Attestations
Beyond basic signatures, attach attestations to your images: SBOM attestations, SLSA provenance attestations, and vulnerability scan results. Cosign's attest command and Notation's plugin system both support rich attestations.
Registry Support
Not all registries support OCI reference types equally. Docker Hub, GitHub Container Registry, Azure Container Registry, AWS ECR, and Google Artifact Registry all support Cosign signatures. Notation support is strongest in Azure ACR and AWS ECR.
If your registry does not support OCI reference types, Cosign can fall back to storing signatures as separate tagged images, but this is a compatibility mode that may not work in all environments.
How Safeguard.sh Helps
Safeguard.sh integrates with OCI signing workflows to verify image signatures and attestations as part of its supply chain analysis. It checks that images are signed by expected identities, validates SBOM and provenance attestations attached to images, and alerts when unsigned or incorrectly signed images appear in your environment. Safeguard.sh provides a single pane of glass for container integrity verification across all your registries and signing tools.