Why This Matters

Back in 2015, DCT launched with the goal of giving developers a way to verify the integrity and publisher of container images. It was built on The Update Framework (TUF) and used Notary v1.

Fast forward to 2025: Notary is no longer actively maintained, the industry has evolved, and fewer than 0.05% of Docker Hub image pulls use DCT. Microsoft is dropping support in Azure Container Registry, and now Docker is formally beginning to retire DCT. This starts with Docker Official Images (DOI) on August 8th, 2025.

If you're using DCT in your pipelines, things may already be breaking.

But there’s good news: the ecosystem is moving forward through Sigstore, an open standard built for the modern software supply chain.

Supply Chain Security & Provenance

Provenance is becoming a critical part of how we secure the modern software supply chain. At its core, it’s about traceability: being able to answer where a software artifact came from, how it was built, and who was responsible at each stage of the process. Threat actors continue to increasingly target dependencies, build systems, and distribution infrastructure, meaning verifiable metadata about your software’s origin is really important. Being able to establish the provenance of your container images helps teams make informed, trustworthy decisions about what they built, run, and deploy. It’s a key building block for adopting frameworks like SLSA and practices like zero trust, and is top of mind for teams in highly regulated environments.

But knowing what happened during a build isn’t enough, you also need a way to attest to that information in a way that others can verify, without adding unwanted friction. So when you think, “why do I need Sigstore?” - that’s the reason. Sigstore is an open-source project that enables cryptographic signing of software artifacts like container images using standard tooling like Cosign, Fulcio, and Rekor.

Unlike DCT, which relied on TUF until the upstream Notary codebase was no longer actively maintained, Sigstore has an active community of contributors and is integrated into a long list of leading enterprise vendors.

What is Sigstore?

Sigstore makes it easy to integrate signing and verification into your CI/CD pipeline without the need for custom certificate infrastructure requirements. You can use keyless signing (via OIDC), or generate and manage your own keys.

While both Sigstore and TUF aim to improve the same software supply chain security issues, they address different layers of the trust and verification problem. For instance, TUF focuses on securing software update systems. It defines certain roles (such as root, targets, and snapshots) as well as providing a metadata-driven approach to protect against rollback attacks or mix-and-match attacks. TUF’s strength and differentiation is in its resilience, so even when some keys are compromised, it can still recover securely.

Whereas, Sigstore is designed specifically for artifact signing and transparency, especially within CI/CD-related contexts. Likewise, Sigstore offers a developer-friendly approach to cryptographic signing, as stated already, it leverages OIDC-identity (keyless) signing, open and auditable transparency logs through Rekor, and dedicated integration with Fulcio for certificate issuance.

Fundamentally, these two approaches have key distinctions in that Sigstore ties identities to signatures (like Github Identity), whereas TUF focuses only on robust update metadata and key delegation. If you’d like to learn more about how these two solutions differ, Bob Callaway and Dan Lorenc delivered a session at Kubecon Valencia on the topic of why Sigstore was created.

Cloudsmith + Sigstore = Built-in Signing

Again, Cloudsmith already has native support for Sigstore's Cosign. When you enable “cosign signing" for your repository, every Docker image uploaded to a Cloudsmith repository is automatically signed using a repository-specific ECDSA key.

Here’s how it works:

• An ECDSA private key is generated when you create a repository.
• Images are signed automatically on upload using this key.
• You can download the matching public key to verify signatures.
• Or you can use your own Cosign keypair and upload external signatures via the cosign sign command.

This means Cloudsmith customers already have a modern, secure signing solution in place without the need to scramble around for a replacement DCT.

Migrating from Docker Content Trust to Sigstore (Cosign)

To recap, DCT was built on Notary v1 and TUF, which allowed for signature-based verification of container images. But with DCT now deprecated and official support ending, it's time to transition to modern, open tooling.

Here is how to migrate to Cosign with Cloudsmith:

1. Stop using DCT

If you have DOCKER_CONTENT_TRUST=1 flag set in your environment, unset it. Continuing to use DCT after August 8, 2025, will cause failures when pulling Docker Official Images. Unsetting the below environment variable will avoid any unwanted pull failures:

unset DOCKER_CONTENT_TRUST

2. Verify Docker images with Cosign

To verify a signed image from Cloudsmith:

cosign verify \
--key public-ecdsa-key.pem \
--private-infrastructure=true \
docker.cloudsmith.io/<workspace>/<repo>/alpine:<tag-or-digest>

The --private-infrastructure=true feature flag tells Cosign not to query the Rekor transparency log, which is appropriate since Cloudsmith-hosted signatures are private by default.

Retrieving the public key

In scenarios where you’re using a default Cloudsmith-managed keypair, you’ll need to download the associated ECDSA public key (making sure to replace workspace and repo with your actual Cloudsmith workspace and repository names):

curl -o public-ecdsa-key.pem https://docker.cloudsmith.io/workspace/repo/cosign.pub

3. Sign images yourself (totally optional)

Prefer signing artifacts manually? You can generate and upload Cosign signatures directly:

cosign generate-key-pair
cosign sign \
  --key cosign.key \
  docker.cloudsmith.io/<org>/<repo>/alpine:<tag>

Then upload both the image and signature to Cloudsmith. We’ll store and associate them automatically.

A note on Rekor and Transparency Logs

Cloudsmith does not log signatures to Rekor when signing on upload, because most customers use private repositories. As a result:

• Cosign will warn if you attempt to verify without setting --private-infrastructure=true.
• To avoid confusion, always include the flag when verifying Cloudsmith-hosted signatures:

WARNING: "docker.cloudsmith.io/<workspace>/<repo>/alpine:<tag>" appears to be a private repository. Please confirm uploading to the transparency log at "https://rekor.sigstore.dev"

f you want to use Rekor for transparency, you can opt into it by signing manually with Cosign and uploading both the signature and the image to Cloudsmith.

At Cloudsmith, we embrace open-source. By migrating from Docker Content Trust to Sigstore (via Cosign), you're adopting an open, scalable approach to supply chain security, while simultaneously staying compliant and adhering to industry best practices. And with Cloudsmith, this migration is already built in.