Cryptographic Container Signing: Sigstore, Cosign and Image Provenance Verification
Container images pass through source repositories, build services, registries and deployment environments before an application begins running. Each transfer creates an opportunity for accidental replacement, unauthorised modification or confusion over which build should be trusted. Cryptographic signing addresses this problem by linking a specific image digest to a verified signer, while provenance records explain where and how the image was produced. Sigstore and its Cosign command-line tool have become widely used parts of this process because they support identity-based signing, public transparency records and integration with automated delivery workflows. In 2026, these controls are no longer limited to specialist security teams. They can be introduced gradually into ordinary container workflows without requiring developers to understand every detail of public-key infrastructure.
Why Container Images Need Cryptographic Signing
A container registry can confirm that an image was uploaded successfully, but storage alone does not prove that the image came from the expected development team. Access credentials may be stolen, automation accounts may be misconfigured, and an attacker may attempt to publish a modified image under a familiar name. A signature provides an additional trust signal by connecting the image’s cryptographic digest to a recognised person, service account or continuous integration workflow. Verification can then answer a practical question before deployment: was this exact image signed by an identity that the organisation has explicitly approved?
The digest is central to this process. A tag such as latest, stable or 1.4 is a convenient reference, but registry tags can normally be moved to another image. A SHA-256 digest identifies the content of one particular image manifest. If any relevant content changes, the digest changes as well. Signing and verifying the digest therefore prevents a valid signature from being silently reused for a different build. Production records should retain digest-based references even when human-readable tags remain available for navigation and release management.
Signing does not establish that the application is free from vulnerabilities or malicious code. It proves that the signed content has not changed and that the signature meets defined identity requirements. This distinction matters because a compromised build workflow can still create and sign a harmful image. Container signing should therefore work alongside code review, branch protection, dependency scanning, secret management and controlled build permissions. Its main value is providing a reliable chain of custody between an approved build process and the environment in which the resulting image is used.
How Sigstore Connects a Signature to an Identity
Traditional code signing usually depends on a private key that must be generated, stored, backed up, rotated and protected over a long period. Sigstore offers an identity-based alternative commonly described as keyless signing. The term does not mean that no cryptographic key exists. Cosign creates a temporary key pair for the signing operation, but the private key is held briefly in memory rather than maintained as a permanent secret. The signer authenticates through an OpenID Connect provider, allowing the signature to be connected to an existing identity such as a developer account or an automated workflow.
Sigstore’s certificate authority, Fulcio, checks the OpenID Connect token and issues a short-lived signing certificate that binds the temporary public key to the authenticated identity. Public Fulcio certificates are designed to remain valid for only a few minutes. The temporary private key is then discarded after signing. This approach reduces the operational burden and exposure associated with long-lived signing keys, although it makes the security of the identity provider and the permissions assigned to the build workflow especially important.
The signing event is also recorded through Rekor, Sigstore’s transparency log. The log stores verifiable metadata about signatures and attestations in an append-only structure that can be audited for unexpected activity. A verifier can check that the signature was created while the certificate was valid and that the event was recorded in the expected log. Transparency does not prevent every form of misuse, but it makes signing activity visible and harder to alter without detection. Organisations using keyless signing should monitor entries connected to their repositories and workflow identities rather than treating the log as a record that nobody needs to review.
Signing and Verifying Container Images with Cosign
Cosign is the main command-line tool used to sign and verify container images with Sigstore. A simple keyless signing command follows the form cosign sign registry.example.com/team/application@sha256:DIGEST. In an interactive session, Cosign can request authentication through a supported identity provider. In continuous integration, it can use an OpenID Connect token issued to the running workflow. The image must normally be pushed to a compatible registry before signing because signatures and related records are stored alongside the image as OCI artefacts.
Cosign also supports self-managed keys and keys held by cloud key-management services or hardware devices. These options remain useful when an organisation requires private trust infrastructure, offline signing, formal key custody or compatibility with an established public-key policy. The important requirement is consistency: the team must know which signing model applies, who controls the trusted key or identity, and how verifiers obtain the correct trust information. Mixing several undocumented signing methods makes incident investigation and policy enforcement more difficult.
Current Cosign workflows can associate more than a basic signature with an image. Attestations may carry structured claims such as build provenance or a software bill of materials. These records are separate from the image layers, so adding an attestation does not change the application image digest. Cosign can display the supply-chain records linked to an image, including signatures, attestations and SBOM-related artefacts. Registry behaviour still varies, particularly for deletion and lifecycle management, so teams should test signing, retrieval, replication and clean-up procedures with the registry products they actually use.
Checking Image Identity, Integrity and Provenance
A useful verification policy must define the identity that is expected to sign the image. Running Cosign without a clear identity expectation may confirm that somebody created a valid Sigstore signature, but it does not establish that the signer belongs to the correct project. Keyless verification therefore includes both the certificate identity and the OpenID Connect issuer. For an automated workflow, the expected identity may contain the repository, workflow file and branch reference. The verification rule should be narrow enough to reject signatures from unrelated repositories or unapproved workflows.
Cosign also checks that the digest embedded in its signature payload matches the image being verified. A typical verification command uses cosign verify with the full image reference, the expected certificate identity and the expected OIDC issuer. Successful output should be treated as structured evidence rather than a simple green signal. Review which image digest was checked, which identity signed it, which issuer authenticated that identity and whether transparency information was validated. Verification failures should stop promotion or deployment instead of being converted into warnings that teams routinely ignore.
Provenance answers questions that a signature alone cannot. Under the SLSA model, provenance is verifiable information describing where, when and how an artefact was produced. For a container image, it can identify the source repository, source revision, build workflow, builder identity and other details of the build process. Verification should compare these claims with an organisation’s expectations. An image may carry valid provenance but still be unsuitable if it was built from an unapproved branch, an unexpected repository or an untrusted workflow. Authentic metadata must therefore be checked against policy rather than merely confirmed as present.
Integrating Image Verification into Delivery Workflows
The most reliable pattern is to build an image once, push it to the registry and capture the resulting digest. The workflow should sign that digest rather than rebuilding the image separately for each environment. Provenance and SBOM attestations can then be generated for the same subject digest. Development, testing and production stages promote this immutable reference without changing its content. This removes ambiguity about whether different environments are running equivalent builds and provides one traceable object for review, approval, rollback and incident response.
Verification should take place at more than one point. A release workflow can verify the image before it is promoted to a production registry or marked as approved. Deployment tooling can repeat the check before updating a workload. Kubernetes environments can use Sigstore Policy Controller as an admission control layer, allowing or rejecting images according to signature and attestation policies. The controller can also resolve mutable tags so that the admitted digest remains tied to the image that was checked. This reduces the risk of a tag being redirected between admission and execution.
Enforcement should be introduced in stages. Teams can begin by collecting verification results and identifying unsigned images, unexpected workflow identities and registry compatibility problems. A warning phase allows legacy workloads to be mapped without blocking urgent operations. Policies can then be enforced for a limited set of namespaces or services before wider adoption. The final rules should state which registries are accepted, which signer identities are trusted, whether provenance is mandatory, which source repositories and branches are permitted, and how emergency exceptions are approved and recorded.
Operational Limits and Sensible Security Practices
A valid signature does not compensate for weak controls around the signing identity. If an attacker can modify an approved workflow or obtain permission to request its OpenID Connect token, the resulting image may appear to come from a trusted source. Repository permissions, protected branches, workflow review and restricted automation credentials remain essential. Signing steps and third-party workflow components should also be pinned and reviewed so that an unplanned update cannot change the build or signing process without scrutiny.
Trust material requires lifecycle management even when ephemeral keys are used. Verifiers depend on trusted certificate roots, transparency-log information and identity rules. Air-gapped environments may need bundles containing the signature, certificate, timestamp and proof of log inclusion, together with an approved copy of the relevant trust roots. Private Sigstore deployments require additional care because the organisation becomes responsible for operating and protecting its own Fulcio, Rekor and trust-distribution services. A private installation should be chosen for a defined compliance or operational reason rather than simply because it appears more controlled.
The clearest measure of success is not the number of signed images but the number of deployments that are based on verified evidence. A mature process can trace a running digest back to its signature, signer identity, source revision, build workflow, provenance statement and approval record. It also has a documented response for failed verification, unexpected log entries and compromised identities. Sigstore and Cosign provide the cryptographic and operational building blocks, but each organisation must define the expectations that turn those records into meaningful trust decisions.
