Docker Supply Chain Security: Sigstore and Cosign, Explained From Zero
How the container ecosystem proves an image is really what it claims to be, who really built it, and that nobody tampered with it on the way to your cluster.
Imagine buying medicine from a pharmacy. You don’t personally test each pill for authenticity — instead you trust a chain of tamper-evident seals, batch numbers, and manufacturer stamps that would be very hard to fake convincingly, and very easy for anyone to check. Container images used to have almost none of this. An image pulled from a registry was, by default, taken on faith: faith that the tag pointed to what you expected, faith that nobody altered it after it was built, faith that it actually came from the team it claimed to. Supply chain security tooling — and specifically the Sigstore project, with its signing tool Cosign at the center — exists to replace that faith with something checkable: cryptographic proof that a specific image was produced by a specific, verifiable source and has not been altered since.
1What Is Software Supply Chain Security, and Why Containers Need It?
The problem isn’t new — but containers made it dramatically easier to exploit at scale.
What “supply chain” means for software
A software supply chain is every step and party involved in turning source code into something that ends up running in production: the developers who write it, the systems that build it, the registries that store it, and the pipelines that deploy it. A supply chain attack targets any weak link in that chain instead of attacking the final running application directly — compromising a build server, injecting malicious code into a dependency, or replacing a legitimate image with a tampered one somewhere between being built and being deployed.
Why container images are an especially attractive target
A container image is a convenient, self-contained unit that gets pulled and trusted automatically by thousands of machines, often with no human reviewing each pull individually. If an attacker can push a malicious image to a registry under a trusted name, or intercept and swap an image somewhere in the pipeline, the attacker’s code runs wherever that image is deployed — potentially across an entire fleet — without ever needing to compromise the target systems directly.
It’s the difference between a sealed medicine bottle with a tamper-evident cap and an open bowl of loose pills on a counter. Both might contain exactly what they claim to — but only one lets you actually verify that before you take anything, and only one makes tampering obvious if it happens.
Where signing fits
Image signing is the core building block of container supply chain security. A trusted party cryptographically signs an image after building it, producing a signature that can later be checked by anyone who pulls that image, proving both who signed it and that its contents have not changed since. Sigstore is the project that made this practical, and Cosign is the command-line tool most commonly used to actually produce and check these signatures for container images.
Where it came from
Verifiable information about who built an artifact, from what source, and through what process.
Unaltered since signing
Cryptographic assurance that an artifact is byte-for-byte identical to what was originally signed.
Proof of origin
A cryptographic value produced with a signer’s private key, which anyone can check against the artifact using the corresponding public key.
A signed claim
A signed statement about an artifact — such as “this image was built from this exact source commit” — beyond just “this image was signed by X.”
Signing an image doesn’t make it “safe” in the sense of being free of vulnerabilities — it only proves who produced it and that it hasn’t been altered since. Vulnerability scanning and signing solve two different, complementary problems.
2The Building Blocks of Sigstore’s Architecture
Sigstore is not one tool — it’s a small set of cooperating services with very specific jobs.
1. Cosign
The client-side tool developers and pipelines actually run to sign container images, verify signatures, and attach attestations. It’s the piece most people interact with directly.
2. Fulcio
A certificate authority built specifically for short-lived, identity-bound signing certificates. Instead of managing a long-term private key yourself, Fulcio issues a certificate tied to a verified identity — such as a specific login through an existing identity provider — that’s valid for only a few minutes.
3. Rekor
A public, tamper-evident transparency log that records every signing event. Once an entry is written to Rekor, it becomes a permanent, independently verifiable record that a specific signature was created at a specific time — making it detectable if anyone later tries to claim a signature never happened, or tries to backdate one.
4. OIDC Identity Providers
Existing identity systems — the same kind used to log into everyday developer tools — that Fulcio relies on to confirm who is actually requesting a signing certificate, rather than Sigstore needing to run its own separate identity system.
Why this combination matters
Traditional code signing required generating, protecting, and rotating a long-lived private key — a real operational burden, and a single point of failure if that key ever leaked. Sigstore’s design deliberately avoids long-lived keys for most everyday use, replacing them with short-lived certificates issued only after identity verification, combined with a public log that makes every signing event independently auditable forever, whether or not the signer still has the certificate that produced it.
flowchart TB
A["Developer / CI Pipeline"] -->|"Authenticate via OIDC"| B["Fulcio
Certificate Authority"]
B -->|"Issue short-lived
signing certificate"| A
A -->|"Sign the image digest"| C["Cosign"]
C -->|"Record signing event"| D["Rekor
Transparency Log"]
C -->|"Attach signature"| E["Container Registry"]
F["Verifier / Cluster"] -->|"Pull image + signature"| E
F -->|"Check signature validity
and log entry"| D
Sigstore is not itself a container registry, and it doesn’t store the image content. It stores and verifies signatures and certificates; the signed image itself still lives in whatever ordinary registry it was pushed to.
3How “Keyless” Signing Actually Works
No key file is generated by the signer, yet a real cryptographic signature still results.
The phrase “keyless signing” confuses people at first, because a signature is still, mathematically, produced with a private key — the “keyless” part refers to the fact that the signer never has to generate, store, back up, or protect that key themselves. Instead, a brand-new key pair is generated automatically at signing time, used once, and then discarded, while a certificate binding the public half of that pair to a verified identity is what actually gets kept.
Identity Verification
The signer proves their identity through an existing OIDC login flow — the same kind of “sign in with” flow used by countless everyday web services — rather than presenting a pre-existing signing key.
Ephemeral Key Pair Generation
Cosign generates a brand-new, temporary public/private key pair on the fly, used only for this single signing operation.
Certificate Issuance
Fulcio issues a short-lived certificate binding the new public key to the verified identity from step one, valid only for a few minutes.
Signing the Image
Cosign uses the temporary private key to sign the image’s cryptographic digest, then immediately discards the private key — it is never needed again.
Transparency Logging
The signature, certificate, and signed artifact reference are recorded in Rekor, creating a permanent, publicly checkable record of the entire event.
Because the private key never persists anywhere, there’s nothing long-lived for an attacker to steal in order to forge future signatures under that identity. Every signing event instead depends on the signer being able to re-authenticate through the identity provider at the moment of signing — a fundamentally different, and for many teams considerably lower-risk, security model than protecting a single long-term secret indefinitely.
4The Full Lifecycle of a Signed Image
Signing is one moment in a much longer chain of custody, from source code to a running container.
sequenceDiagram
participant Dev as Developer / CI
participant Build as Build Pipeline
participant Reg as Registry
participant Rekor
participant Cluster as Deployment / Cluster
Dev->>Build: Trigger build from source
Build->>Build: Produce image
Build->>Reg: Push image
Build->>Cosign: Sign image digest
Cosign->>Rekor: Log signing event
Cosign->>Reg: Attach signature
Cluster->>Reg: Pull image
Cluster->>Cosign: Verify signature
Cosign->>Rekor: Confirm log entry
Rekor-->>Cosign: Entry valid
Cosign-->>Cluster: Verification passed
Cluster->>Cluster: Allow deployment
Why the order of operations matters
Signing happens as close to the actual build step as possible — ideally automatically, inside the build pipeline itself, immediately after the image is produced — rather than as a manual, after-the-fact step performed by a separate team later. The closer signing sits to the build, the smaller the window during which an unsigned or tampered image could slip through unnoticed.
Verification happens at the boundary, not just once
Verification is meant to occur at every point where trust matters, not only once at the very end. A registry can require signatures before accepting a push, a deployment pipeline can require them before promoting an image to a new environment, and a cluster’s admission controller can require them again immediately before allowing a container to actually start — each check independently confirming the same underlying proof.
5What Gets Signed: Images, SBOMs, and Attestations
A signature can cover far more than just “this image is authentic.”
While signing the image itself is the most basic use case, Cosign and Sigstore are commonly used to sign other supply-chain artifacts associated with that image as well, each answering a different question a consumer of the image might want answered before trusting it.
“This image is authentic”
Proves the image content matches exactly what a specific identity signed, and hasn’t changed since.
Software Bill of Materials
A structured inventory of every component and dependency inside the image, which can itself be signed to prove the list is accurate and unaltered.
“Built this way, from this source”
A signed statement describing exactly how the image was built — the source repository, commit, and build system used — letting consumers verify the build process itself, not just the output.
Scan results, signed
The output of a security scan, signed so consumers can trust the reported results came from a legitimate scan and weren’t altered or fabricated.
Why signed metadata matters as much as the image itself
An unsigned SBOM or an unsigned scan report can simply be replaced with a more favorable-looking fake, defeating the purpose of generating them at all. Signing these artifacts the same way the image itself is signed closes that gap, letting downstream policy decisions — like “only deploy images with zero critical vulnerabilities” — be enforced against data that has itself been verified as genuine.
This connects directly to broader supply chain frameworks like SLSA (Supply-chain Levels for Software Artifacts), which define graduated levels of build integrity and provenance guarantees — signed attestations are one of the concrete mechanisms used to satisfy those higher levels.
6Docker Content Trust vs Sigstore and Cosign
Docker actually shipped an earlier image-signing system years before Sigstore existed.
Docker Content Trust, built on an underlying project called Notary, was an earlier approach to image signing, requiring users to generate and manage their own long-lived signing keys directly. It works, but it places the full operational burden of key generation, secure storage, backup, and rotation onto the signer — exactly the burden Sigstore’s keyless approach was designed to remove.
| Aspect | Docker Content Trust | Sigstore / Cosign |
|---|---|---|
| Key management | Signer generates and protects long-lived keys | Short-lived, automatically issued certificates by default |
| Identity model | Tied to the key itself | Tied to a verified OIDC identity |
| Transparency | No public transparency log | Every signing event recorded in Rekor |
| Scope | Focused specifically on image signing | Covers images, SBOMs, and provenance attestations broadly |
| Ecosystem adoption | Primarily tied to Docker’s own tooling | Broadly adopted across many registries and CI systems |
Docker Content Trust is like carrying a physical rubber stamp everywhere and being personally responsible for never losing it or letting anyone else use it. Sigstore’s keyless model is more like a notary who checks your ID on the spot each time and stamps the document themselves, so there’s no stamp for you to protect at all.
7Advantages, Disadvantages, and Trade-offs
Supply chain signing solves real problems, but it does introduce new dependencies of its own.
Advantages
- Removes the burden of generating and protecting long-lived private signing keys for most use cases
- Ties signatures to real, verifiable identities rather than to a key that could be anyone
- Creates a permanent, publicly auditable record of every signing event through the transparency log
- Extends naturally to SBOMs and provenance attestations, not just image content
- Free and open source, with broad adoption across major registries and CI platforms
Disadvantages / Trade-offs
- Keyless signing depends on Fulcio and Rekor being reachable at signing and verification time
- Teams with strict offline or air-gapped requirements need extra planning around infrastructure dependency
- Enforcing verification everywhere it matters requires deliberate configuration across registries, pipelines, and clusters
- A signature alone says nothing about whether the image’s content is actually free of vulnerabilities
- Adds a new step to build pipelines that must itself be configured correctly to be meaningful
8Security Considerations
Signing infrastructure itself becomes a high-value target the moment it’s relied upon.
Protecting the identity that does the signing
Because keyless signing ties trust to an identity rather than a static key, protecting the accounts and systems that can authenticate as that identity — especially automated CI pipeline identities — becomes just as important as key protection ever was under older signing models. Anyone who can authenticate as a trusted build pipeline can produce a validly signed, but potentially malicious, image.
Verification must actually be enforced, not just available
Signing an image accomplishes nothing on its own if nothing downstream actually checks the signature before trusting the image. A common and serious gap is signing diligently in the build pipeline while leaving deployment targets configured to accept any image, signed or not — turning a real security control into pure theater.
Verification at deploy time
Configure clusters and pipelines to actually reject unsigned or invalidly signed images, not merely to generate signatures.
Pipeline credentials matter
Treat the identity your build pipeline authenticates as with the same care as any other high-privilege credential.
Verify against a known allowlist
Verification policies should check that a signature came from a specific expected identity, not merely that a valid signature exists from anyone at all.
Watch Rekor for surprises
Unexpected signing events for a given identity, appearing in the transparency log, can be an early signal of a compromised pipeline.
Verifying that “a signature exists” instead of verifying that the signature came from a specific, expected identity. An attacker who can sign under their own identity will happily produce a technically valid signature for a malicious image.
9Monitoring, Logging, and Metrics
Because Rekor is public and permanent, it doubles as a built-in audit trail.
The transparency log as an observability source
Every signing event recorded in Rekor is independently queryable, meaning teams can monitor for signing activity tied to their own identities as an ongoing security signal, not just a one-time verification check. A sudden spike in signing events, or events from an unexpected identity, is directly visible without needing to build separate logging infrastructure.
Pipeline-level metrics
Build pipelines can track how many images were successfully signed versus how many builds completed without signing — a gap between those two numbers usually indicates a misconfiguration worth investigating.
Verification failure rates
Deployment systems that enforce signature verification should track and alert on rejection events, since a sudden rise in rejected deployments can indicate either a legitimate pipeline problem or a genuine attempted supply chain attack.
Admission controller decisions
In Kubernetes environments, admission controllers enforcing signature policy typically expose their own allow and deny decisions as auditable events, providing visibility at the very last checkpoint before a container actually runs.
10Design Patterns and Anti-Patterns
Signing well is mostly about closing the gap between “signed” and “actually enforced.”
Pattern: sign in CI, verify at every boundary
A mature pattern signs images automatically as part of the build pipeline, using the pipeline’s own verifiable identity, and then verifies that signature independently at every subsequent boundary the image crosses — registry push, promotion between environments, and cluster admission — rather than trusting a single check performed once.
Pattern: identity-scoped verification policy
Rather than a blanket “must be signed” rule, mature verification policies specify exactly which identities are trusted to sign images destined for which environments — for example, requiring production deployments to be signed specifically by the production release pipeline’s identity, not merely by any valid Sigstore signature.
Problem
Signing images in the build pipeline but never configuring deployment targets to actually require or check that signature.
Why It’s Harmful
The organization gains none of the intended protection while believing it has meaningfully improved its supply chain security posture.
Correct Approach
Pair every signing step with a corresponding, tested enforcement step at deployment time, and periodically verify that unsigned images are genuinely rejected.
Problem
Accepting any validly signed image regardless of which identity produced the signature.
Why It’s Harmful
Anyone capable of authenticating through the same OIDC provider — even an outside contributor with unrelated access — could produce a signature that technically passes verification.
Correct Approach
Scope verification policies to specific, expected signing identities appropriate to each environment, particularly for production deployments.
11Best Practices and Common Mistakes
Habits that turn supply chain signing from a checkbox into an actual control.
Automate signing in CI
Make signing an automatic, non-optional step of the build pipeline rather than a manual step someone might forget.
Sign SBOMs and provenance too
Extend signing beyond the image itself to the metadata consumers actually use to make trust and policy decisions.
Test that rejection actually works
Periodically attempt to deploy a deliberately unsigned or invalidly signed image to confirm enforcement genuinely blocks it.
Scope trust to specific identities
Write verification policies around named, expected signer identities rather than “any valid signature.”
Treating signing as a one-time setup task
Configuring signing once and never revisiting it as pipelines, identity providers, or trusted teams change over time.
Confusing “signed” with “safe”
Assuming a validly signed image is automatically free of vulnerabilities, when signing and vulnerability scanning answer two entirely different questions.
12Real-World and Industry Examples
Sigstore’s adoption has moved quickly from experimental to close to standard practice across the ecosystem.
Major open-source projects
A number of widely used open-source projects sign their official release artifacts and container images using Sigstore, giving downstream users a concrete way to verify they’re running genuine, unmodified releases rather than a compromised mirror or malicious fork.
Container registries with native support
Several major public and cloud-provider container registries have added native support for storing, displaying, and checking Sigstore signatures directly, reducing the integration work needed to adopt signing end to end.
Kubernetes admission policy integrations
Kubernetes-native policy engines commonly support Sigstore-based verification as a built-in admission control rule, letting cluster operators enforce “only signed, trusted images may run” directly at the platform level.
Regulatory and industry momentum
Growing attention to software supply chain risk, following several high-profile real-world supply chain attacks in recent years, has pushed frameworks like SLSA and executive-level software supply chain guidance toward treating signed provenance as an expected baseline rather than an advanced, optional practice.
13Frequently Asked Questions
No. Sigstore’s public infrastructure and Cosign itself are free and open source, maintained as a community project rather than a paid product.
It shifts the security dependency rather than simply removing it — instead of protecting a long-lived key, you’re protecting the identity and authentication flow used at signing time. For many teams, this is easier to secure well in practice, since identity providers already have mature account protection in place.
Since keyless signing and verification depend on reaching these services, an outage can block new signing or verification operations. Teams with strict availability or offline requirements sometimes run private instances of this infrastructure, or fall back to traditional key-based signing for those specific cases.
No. Signing only proves who produced the image and that it hasn’t been altered since. Whether the image’s contents are actually free of known vulnerabilities is a separate concern, typically addressed with vulnerability scanning and, optionally, signed scan attestations.
Yes. Cosign supports traditional key-based signing as well, for teams and situations where the keyless, identity-based model isn’t the right fit.
Sigstore and Cosign are not Docker-specific — they work with container images broadly across the ecosystem, including images built and run through other container tools, and are widely used in Kubernetes environments regardless of which tool originally built the image.
14Summary and Key Takeaways
Supply chain security tooling exists because trusting a container image by default — simply because it came from a familiar-looking registry path — stopped being a safe assumption a long time ago. Sigstore, with Cosign as its primary interface, replaces that blind trust with cryptographic proof: proof of who signed an image, proof that it hasn’t changed since, and, through Fulcio’s identity-bound certificates and Rekor’s public transparency log, proof that can be independently checked by anyone, forever, without requiring the signer to protect a long-lived secret key. Extended to SBOMs and provenance attestations, the same mechanism lets organizations verify not just an image’s authenticity but the honesty of the metadata used to make real deployment decisions about it.
Key Takeaways
- Signing proves origin and integrity, not safety. It’s a complement to vulnerability scanning, not a replacement for it.
- Keyless signing removes long-lived key management by issuing short-lived, identity-bound certificates through Fulcio at signing time instead.
- Rekor makes every signing event permanently and publicly checkable, creating an audit trail that exists independent of whether the signer still has anything to show for it.
- Signing without enforcement accomplishes nothing. Verification has to actually be required at deployment boundaries, not merely made available.
- Verify identity, not just validity. A signature being technically valid doesn’t matter if it wasn’t scoped to check who actually produced it.
- The same mechanism extends to SBOMs and provenance attestations, letting policy decisions rely on verified metadata, not just a verified image.
- Sigstore is ecosystem-wide, not Docker-specific — it’s broadly adopted across registries, CI systems, and Kubernetes tooling.