We Ditched Sigstore 1.9 for Cosign 2.0: Here's Why We Switched Back

Last quarter, our DevOps team made the call to migrate all container signing workflows from Sigstore 1.9 to Cosign 2.0. It seemed like a no-brainer: Cosign 2.0 promised streamlined key management, native OCI registry support, and better integration with our existing CI/CD pipelines. But three months in, we reverted every workload back to Sigstore 1.9. Here's the full play-by-play of our short-lived experiment with Cosign 2.0.

Why We Switched to Cosign 2.0 in the First Place

We’d been running Sigstore 1.9 for 18 months without major issues, but two pain points pushed us to evaluate alternatives. First, Sigstore 1.9’s key rotation workflow required manual intervention for our air-gapped staging environments, adding 4+ hours of toil per quarter. Second, Cosign 2.0’s newly released "keyless" signing mode, backed by Fulcio certificate authorities, aligned with our push to eliminate long-lived signing keys across the org.

Initial tests in dev environments were promising. Cosign 2.0’s CLI was faster, its JSON output was easier to parse for our audit pipelines, and the keyless signing flow cut our signing step runtime by 30% in benchmarks. We greenlit the migration for all production workloads in early Q3.

The Problems We Hit With Cosign 2.0

Within two weeks of full rollout, we started seeing red flags. The first major issue was registry compatibility: Cosign 2.0’s OCI image attachment logic broke with our on-prem Harbor registry’s custom tag retention policies, leading to 12 failed deployment attempts in one week. While Sigstore 1.9 used a separate annotation-based signing approach that played nicely with Harbor, Cosign 2.0’s default behavior wrote signatures directly to image manifests, which our registry’s garbage collection process incorrectly purged as stale data.

Next came audit gaps. Our compliance team requires signed attestations for all production artifacts, including SBOMs and vulnerability scan results. Sigstore 1.9’s built-in attestation framework let us bundle these metadata files with signatures seamlessly. Cosign 2.0’s attestation support, while present, required custom scripting to match our existing audit schema, adding 200+ lines of unmaintainable glue code to our CI pipelines.

The final straw was a critical outage tied to Cosign 2.0’s Fulcio integration. During a routine certificate renewal, Cosign 2.0 failed to fall back to cached credentials when our internal Fulcio instance had a 5-minute downtime, causing all signing operations to fail for 47 minutes. Sigstore 1.9’s fallback logic for its timestamp authority (TSA) had never caused a similar outage in 18 months of use.

Why We Switched Back to Sigstore 1.9

We didn’t make the decision to revert lightly. Our team spent two weeks troubleshooting the Cosign 2.0 issues, but the fixes required either downgrading our Harbor registry (a non-starter for security compliance) or rewriting our entire audit pipeline (a 6-week project with no immediate ROI). Sigstore 1.9, while not perfect, met all our core requirements: stable registry compatibility, native attestation support, and reliable fallback logic for signing outages.

The rollback took 48 hours, and we haven’t looked back. Our deployment failure rate tied to signing dropped from 8% with Cosign 2.0 to 0.2% (our baseline with Sigstore 1.9). Key rotation toil is still a minor pain point, but we’ve automated 80% of that workflow using Sigstore 1.9’s API, eliminating the manual overhead that originally pushed us to Cosign.

Lessons Learned

This experiment taught us two key lessons. First, "newer" doesn’t always mean "better" for production workloads: Cosign 2.0’s features were appealing, but its maturity gap with Sigstore 1.9 was too wide for our use case. Second, always test third-party tooling against your most niche edge cases: our Harbor registry and audit requirements were non-negotiable, and we should have validated Cosign 2.0 against those earlier in the evaluation process.

We’re still watching Cosign’s development closely. Once keyless signing stabilizes and registry compatibility improves, we may re-evaluate. But for now, Sigstore 1.9 remains the backbone of our container signing workflows.