Cosign verifies a signer only when policy names that signer
Cosign signs container images, generic blobs, in-toto attestations, and other artifacts stored through OCI. Its default keyless flow obtains a short-lived certificate from Fulcio after OIDC authentication, records the event in Rekor, and pushes signature material beside the artifact in a registry. Key-based alternatives include an encrypted local keypair, hardware tokens, cloud KMS providers, and a team's own PKI. The choice changes custody, identity, and availability requirements.
Verification is the consequential half. A keyless command should name the expected certificate identity and OIDC issuer. A public-key command should receive the trusted public key through a controlled channel. Finding a mathematically valid signature from an unspecified identity is not an admission policy. Cosign also verifies signatures, certificate chains, transparency-log inclusion, timestamps, and attestations according to the material and flags supplied. Teams must decide which checks are mandatory for each artifact class.
The 63-second test run passed all 98 tests
Our fresh Go 1.24 container installed 788 packages in 115 seconds. The build then succeeded in 150 seconds, and go test completed in 63 seconds with 98 passed and 0 failed out of 98. The checkout contained 481 files, about 63,939 source lines, and occupied 4 MB. It had 17 CI workflow files, a Dockerfile, and a tests directory. Every install, build, and test step in the supplied lab run completed successfully.
Those results cover commit 58aae9e on 3 CPUs and 8 GB of RAM in an unprivileged container with no secrets. We did not authenticate through OIDC, contact Fulcio or Rekor, push to a registry, use a KMS key, or test an admission controller. The 98-test pass is good repository evidence; it is not proof that a particular registry, identity provider, key policy, or offline mirror has been configured safely.
What happened when we ran it
Our measured install, build, and test sequence took 328 seconds in total. The build produced no reported compiler error, and the test command returned a clean result. The lab block contains no dependency vulnerability audit, so this review does not assign an advisory count to the 788-package Go tree. Cosign's recent security release matters independently because it describes a vulnerability fixed in shipped versions, not a result from our package scan.
For everyday installation, users can avoid that source build through release binaries, package managers, the GitHub Action, Kubernetes documentation, or the published container image. Source contributors need Go 1.22 or newer. Production users need registry credentials and one signing identity path. Keyless operation adds OIDC plus Sigstore services; managed-key operation adds KMS policy and recovery; local keys add secure password, backup, and distribution procedures.
Version 3.1.3 fixes a legacy-bundle verification bypass
Release v3.1.3 arrived on August 6, 2026. Its first item resolves GHSA-fx35-mq7g-6g98, described as a verification bypass using an unexpected public key in a legacy bundle. The release also fixes a PKCS#11 panic, adds X.509 certificate-chain support for OCI signing, and adjusts digest selection and blob checksum handling. Verification tools belong on an upgrade path that treats security releases as urgent rather than optional feature updates.
Cosign 2.x is described as stable and still receives periodic fixes, while future major development is moving toward sigstore-go. The troubleshooting section says the active support window includes the newest release and the last v2 release. Mixed fleets should pin exact versions and fixture-test bundles created by every remaining signer. Open issue 2596 shows why: CycloneDX predicate shorthand changed between older versions, causing attestations made by one version to fail verification in another.
Public transparency creates an identity record that cannot be erased
The keyless prompt warns that personal information associated with the signing account, including an email address, may enter a public transparency log and cannot be removed later. That is part of the accountability model, and it requires an organizational identity decision before developers sign from personal accounts. CI workload identities are usually easier to govern because policy can match a repository workflow subject and issuer rather than a person's mailbox.
Air-gapped verification adds another ownership problem. The README labels its section out of date and says most workflows periodically obtain service keys from a TUF repository. Offline bundles can carry verification material, while the isolated side still needs an up-to-date trusted root delivered through a controlled process. cosign save also requires network access before the image and signatures move offline. Run the complete transfer and root-rotation drill before an incident cuts connectivity.
Registry storage can race, linger, or fail during replication
Cosign's caveats say legacy signature objects have a weak registry reference to the artifact. Deleting an image may leave signatures behind, and copying images does not automatically copy their signature relationship. Multiple signatures are maintained through a read-append-write update, so concurrent clients can overwrite one another. Digest signing prevents a moving tag from changing what was signed, but it does not repair registry garbage collection or update semantics.
Issue 5030 reports a v3.1.2 cross-registry failure in cosign save followed by cosign load. When a fresh destination lacks the v3 bundle layer blob, the command can push the manifest first and receive BLOB_UPLOAD_UNKNOWN. A fix pull request was active in August 2026. GitHub showed 6,241 stars, 166 combined issues and pull requests, and a last push on August 24. Cosign is active and capable; deployment quality depends on the verification policy and registry tests built around it.