Why is a cosign verify step with no expected certificate identity or OIDC issuer worthless?

## A signature answers "who", and only if you asked The keyless flow in Sigstore deliberately has no gatekeeper. You authenticate to an OIDC provider, the certificate authority issues a short-lived certificate binding your ephemeral public key to that identity, you sign, and the event is recorded in a transparency log. This is what makes the ecosystem usable — no key distribution, no enrolment ceremony — and it is also why the certificate itself confers no privilege. It attests an identity; it does not attest worthiness. So consider what a bare `cosign verify <artifact>` establishes. It establishes: this signature is cryptographically valid over this digest, and the certificate that made it chains to the Sigstore root. Every one of those facts is also true of a signature made by an anonymous person who pulled your artifact, signed it under their own identity, and published the result. Nothing in that verification distinguishes your release job from them. A release gate built on it accepts anything anyone ever signed through the public chain — the gate is decorative. ### The two flags that make it a real check - `--certificate-identity` pins the exact identity string in the certificate — for a CI job that is typically a workflow or workload identity URI; for a human, an email address. `--certificate-identity-regexp` allows a pattern where the identity legitimately varies. - `--certificate-oidc-issuer` pins the provider URL that asserted that identity. Both are required, and the reason is worth being able to state cleanly. An identity string has no global meaning. `[email protected]` at your corporate SSO and `[email protected]` at some public consumer provider are different principals that happen to render as the same text, and an attacker who can create an account somewhere with a chosen identity string can produce a certificate carrying it. Pinning the issuer without the identity is the mirror failure: you would accept every user of that provider, which for a large public provider is essentially the internet. ### The regexp trap `--certificate-identity-regexp` is where a correct-looking gate quietly reopens. An unanchored pattern matches a substring, so a pattern intended to match one repository's workflow can match an identity that merely *contains* that text, including one an attacker controls the tail or head of. Anchor the pattern and keep it as narrow as the real variation demands; a regexp is a concession to necessity, not the default. ### Key-based verification is a different shape If you sign with `--key`, the public key *is* the identity, and the identity and issuer flags do not apply — you verify against the key you trust. That is not a loophole so much as a different trust anchor with a different cost: you now own key generation, storage, rotation and revocation, which is precisely what keyless was designed to remove. ### What verification still does not tell you Even a correctly pinned verify answers exactly one question: the identity you expected vouched for these exact bytes. It does not say the artifact is free of known vulnerabilities, that it was built from reviewed source, or how it was produced. Candidates who slide from "signature verified" to "artifact is safe" have made the domain's most common category error. Origin, contents and production history are three separate claims, and a signature carries only the first. ### How this shows up in a review When you read someone's release gate, the diagnostic sequence is short. Is this keyless or key-based? If keyless, are both identity flags present? If a regexp is used, is it anchored and does it describe an identity only your build system can obtain? Is the artifact referenced by digest, so the thing verified is the thing deployed? Does the step fail the pipeline when verification fails, or is its exit status swallowed? Most broken gates fail at the first or the last of those.