Sigstore Cosign v2.6.0 landed in mid-2025 as the last v2.x feature release before the planned v3.0 cutover, and v2.6.2 followed in autumn with quality-of-life fixes. The release is best understood as a staging area: it adds the four behaviours that become defaults in v3, gates them behind opt-in flags, and lets teams run them in production before the major version forces the change. We deployed v2.6 in three environments — GitHub Actions, GitLab self-hosted, and an internal Kubernetes admission controller — and the experience is the smoothest Cosign upgrade since the v1-to-v2 jump in early 2023.
What does --new-bundle-format actually do?
Cosign v2.6 introduces --new-bundle-format, which packages the signature, the signing certificate, the inclusion proof for the transparency log, and the timestamp signature into a single artifact called a "bundle". Pre-2.6, those four artifacts lived in separate OCI layers in the registry, which meant offline verification required pulling four blobs and threading them through cosign verify-blob arguments. With the new bundle format, one file is sufficient:
# Sign a container image and emit a new-format bundle
cosign sign \
--new-bundle-format \
--output-signature signature.bundle \
--yes \
registry.internal/myapp:${GIT_SHA}
# Verify offline using only the bundle and a trusted root
cosign verify \
--new-bundle-format \
--bundle signature.bundle \
--trusted-root /etc/sigstore/trusted_root.json \
--certificate-identity-regexp "^https://github.com/acme/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
registry.internal/myapp:${GIT_SHA}
The bundle file is roughly 18 KB for a typical sign — small enough to attach to a Slack message or store next to an SBOM in a release asset.
What about the --trusted-root flag?
--trusted-root accepts a JSON document describing which Fulcio CAs, Rekor instances, and timestamp authorities a verifier should trust. Pre-2.6, Cosign hardcoded the public-good Sigstore instance trust roots and required custom builds (or environment variables) to override. With v2.6 the public instance trust root is still the default, but anyone running a private Sigstore deployment can publish a trusted_root.json and have their verifiers consume it. This is the change that unlocks key rotation without client redeployment — when the Fulcio root rotates, you publish a new trusted-root document, and clients pick it up on next refresh.
# Create a trusted-root document for a private Sigstore deployment
cosign trusted-root create \
--certificate-chain /etc/pki/fulcio-internal-chain.pem \
--rekor-url https://rekor.internal:443 \
--tsa-certificate-chain /etc/pki/timestamp-internal.pem \
--out trusted_root.json
How does in-toto statement signing work?
The other notable v2.6 change is cosign attest --statement — you pass a complete in-toto v1.0 statement (with the _type, subject, predicateType, and predicate fields already populated) rather than just a predicate that Cosign wraps. This matters when an upstream build system (Tekton Chains, GitHub Actions' attest-build-provenance action, or a homegrown SLSA generator) already produces a complete statement; the previous workflow would unwrap it, re-wrap it, and double the work. Verifying the subject digest now happens client-side using sigstore-go's verification API, which closes the door on a subtle confusion between "subject as digest" and "subject as URI" that has caused real bugs in the in-toto ecosystem.
What is the actual difference between v2.5 and v2.6?
We compared v2.5.3 (May 2025) against v2.6.2 (October 2025) on the four flows we run in production:
| Workflow | v2.5.3 behaviour | v2.6.2 behaviour | | --- | --- | --- | | Sign container in CI | 1 signature + 1 cert OCI layer | 1 bundle artifact (opt-in) | | Verify offline | 4 files + custom plumbing | 1 bundle + trusted-root | | Sign attestation | Wraps user predicate | Accepts full in-toto statement | | Rekor URL configuration | CLI flag per invocation | SigningConfig file | | Trust root rotation | Rebuild + redeploy Cosign | Publish trusted_root.json |
None of the v2.5 behaviour was removed in v2.6 — every change is gated behind a new flag — which is why the migration is low-risk. Cosign v3.0, which Sigstore has been previewing in release blog posts, flips the defaults so the new behaviour is on and the old behaviour requires explicit opt-out.
What about Rekor v2 support?
Rekor v2 reached GA in mid-2025 and runs the transparency log against a tiled architecture that is significantly cheaper to operate. Cosign v2.5.1 added support for trusted-root create --rekor-version 2 and v2.5.3 added support for multiple Rekor services in the same trusted root, useful when migrating from Rekor v1 to v2 with overlap. v2.6 polishes the experience: the same --bundle artifact embeds the inclusion proof from whichever Rekor wrote it, so verifiers do not need to know in advance which version produced the signature.
How should teams plan the Cosign v3 migration?
Three steps. First, deploy v2.6 with --new-bundle-format enabled in non-blocking mode for one quarter — produce bundles in CI but do not gate deploys on them yet. Second, publish a trusted_root.json to a known location (we use the same OCI registry as our images, tagged cosign-trust:latest), and verify that all consumers can read it. Third, when Cosign v3.0 drops, the upgrade should be a no-op for any pipeline already on the v2.6 opt-ins; the cleanup step is removing the --new-bundle-format flag because it becomes the default.
How Safeguard Helps
Safeguard ingests Cosign v2.6 bundle artifacts and trusted-root documents as first-class evidence objects, mapping signatures, attestations, and SBOMs back to a single asset identity. Griffin AI verifies signature chains across an organisation's entire image fleet and flags drift — images that lost their signature in a registry mirror, signatures that point to a retired Fulcio root, or attestations whose builder identity does not match the policy. Policy gates can require a valid new-format bundle plus a fresh SLSA provenance attestation before a deploy proceeds, and the multi-tool aggregator reconciles Cosign signatures with Tekton Chains, GitHub attest-build-provenance, and Notary v2 signatures so a single asset has one verification view regardless of who signed it. For teams already on Cosign 2.6, Safeguard turns the bundles into policy decisions.