cosign

Cosign v3 is now available

The past few years have been incredible in the Sigstore ecosystem, seeing Sigstore-signed in-toto attestations be adopted by Homebrew (May 2024), PyPI (November 2024), Maven Central (January 2025), model signing in NVIDIA’s NGC (July 2025), and several others. These deployments make use of great Sigstore features, like the ability to verify content offline, being able to fetch new verification key material with The Update Framework, and the ability to use a tile-based transparency log that’s much easier to operate and scale.

Verifying Sigstore Bundles as an End User

There’s a mnemonic for quickly determining if a bicycle is safe to ride: “ABC” for checking the air in the tires, ensuring the brakes are functional, and checking the chain. It doesn’t definitively answer the question “is this bike safe?” but it does give you a quick starting point for your assessment. Let’s say you download some software and it comes with a Sigstore bundle. Similarly, there isn’t a quick, definitive answer to “is this software safe to use?

cosign Verification of npm Provenance, GitHub Artifact Attestations, and Homebrew Provenance

One of the features of the cosign v2.4.0 release allows you to verify attestations in the bundle format used by npm provenance, GitHub Artifact Attestations, and Homebrew provenance. This is part of all Sigstore clients supporting the bundle format as outlined in the community roadmap. We’ll show how to perform that verification for each ecosystem, and explain some of the details involved. You’ll notice these examples follow the same general pattern of getting an artifact to verify, getting the bundle that contains the signed attestation about that artifact, and then providing a verification policy to cosign via command line flags.

Sigstore Announcement: New TUF Trust Root and Client Compatibility

New TUF Trust Root We are planning to publish a new TUF trust root for Sigstore. This update does not contain any functional changes, but it does update to the latest version of the TUF specification. This means that older clients may not be able to load it properly. The current compatibility is as follows: Cosign Releases >= v2.2.0 (v2.2.0 released Aug 31st 2023) work. Older Cosign clients (< v2.2.0) will not work v1.

Sigstore Announcement: No Longer Publishing Cosign Releases to GCS Bucket

We are announcing that we will stop publishing Cosign releases to the GCS bucket named cosign-releases. The current v2.1.1 release of Cosign is the last release that will be pushed to the bucket, and public access to the GCS bucket will be removed on October 31st, 2023. Why are we deprecating the GCS bucket? We are deprecating the GCS bucket because we already use GitHub in the Sigstore community, and it is a reliable and secure platform for hosting release artifacts.

Announcing the Sigstore Clients Special Interest Group (sig-clients)

We are delighted to announce the creation of the Clients Special Interest Group (sig-clients) for the Sigstore project. This exciting new initiative marks the first SIG for Sigstore and serves as an experiment in organizing efforts across the Sigstore project. The sig-clients repository is your one-stop shop for all things related to Sigstore clients across various languages and ecosystems. This group has the following mission: Make Sigstore clients across languages/ecosystems easy-to-write, compatible, and secure by providing shared designs/documentation, data formats, and test suites.

Bringing Privacy and Security Full Circle Through Automated Authentication

This is a Sigstore case study contributed by Max Furman of Smallstep No matter how well you think you secure your software supply chain, the possibility of a breach is always in the back of your mind. We recently had a moment of panic where we thought, “Did someone get access to some things we stored in secrets?” I wondered what damage they’d done and how quickly we could repair it.

Cosign 2.0 Released!

Cosign 2.0 has arrived! Cosign 2.0 follows Sigstore’s General Availability launch, which offers production grade stable services for artifact signing and verification. Cosign’s most significant change is to no longer require COSIGN_EXPERIMENTAL=1, since the Sigstore services are now stable! By default, Cosign will fetch an identity-based certificate from Fulcio when a signing key is not provided, and upload the signature and signing key to Rekor to provide transparency. The following is the list of breaking changes:

Cosign and Policy-controller with GKE, Artifact Registry and KMS

As soon as I came back from KubeCon NA 2022, my first ever in-person KubeCon, I felt re-energized. What a community, full of people eager to share knowledge and expertise with each others, so inspiring. I mostly attended sessions about security best practices for containers and Kubernetes (that’s what excites me these days!). Secure Software Supply Chain (S3C) was almost mentioned everywhere, for good reasons. Sigstore as a new standard for signing, verifying and protecting software, got its first own SigstoreCon as co-located event and hit the General Availability (GA) milestone.

How to become the next Sigstore Evangelist?

How to become the next Sigstore Evangelist? My story began by seeking a solution for signing container images at my company Trendyol. You will appreciate that few solutions were available at that time, almost two years ago. The only solution was DCT (Docker Content Trust) based on a Notary project, which is an implementation of the TUF (The Update Framework) specification, which allows you to verify both the integrity of the image and the publisher of all the data received from a registry by creating and using digital signatures.