If any authenticated user can push a referrer to an image digest, what does signature discovery prove?

## Two questions people conflate - **Discovery:** given a digest, what objects in this repository refer to it? Answered by the registry, cheaply, with no cryptography involved. - **Verification:** is there a signature over this digest that validates, and does it come from a signer my policy accepts? Answered by the verifier, using the payloads discovery handed it. Discovery is a database query. It has exactly the trust properties of the registry's write path, which is to say: anything a principal with push access chose to put there. ## Why the index is attacker-writable The `subject` field is just a field. When a manifest carrying it is pushed, the registry records the back-edge so future referrers queries return it. Registries do not — and largely cannot — enforce that the pusher is entitled to speak about the subject digest: a signature attached later by a scanner, an approval added by a release manager, an SBOM published by a different team are all legitimate uses of exactly that ability. The permission model is per-repository write, not per-subject. In a multi-tenant registry, that means an authenticated low-privilege tenant with push rights into a shared repository can attach objects to a digest belonging to someone else's release. Nothing about the artifact changes; the artifact's digest is untouched and its real signatures are still there. What changes is the *candidate set* every verifier now walks. ## What that buys an attacker, and what it does not It does **not** let them forge trust: they cannot produce a signature that validates against an identity your policy accepts, because that is a cryptographic problem, not a registry-permissions one. The attacks are shaped differently: **Defeating presence checks.** Any policy of the form "proceed if a signature-typed referrer exists" is defeated by one push of a well-formed object with the right artifact type and a payload nobody validates. This is the single most common real-world weakness in home-grown verification, and it is why signing without verifying changes nothing. **Defeating counting.** "Require two signatures" implemented as "the index lists two entries" is the same bug wearing a suit. Two entries is two pushes. A threshold is only meaningful over *distinct verified identities*, and it has to be evaluated after validation, not before. **Poisoning the walk.** If the verifier treats a malformed or non-validating referrer as an error rather than as a non-match, a single junk entry can turn verification into a hard failure for a perfectly good artifact — a denial of the deploy path rather than a bypass of it. Flooding the index with many entries is the volumetric version of the same idea, adding fetch cost and latency to every admission decision. ## The correct verifier shape 1. Discover candidates for the digest, and filter by artifact type client-side rather than assuming a server-side filter was honoured. 2. For each candidate, fetch and validate: does the signature verify over *this* subject digest, and does the identity behind it match one the policy names? 3. Accept if at least one candidate passes. Ignore the rest — a non-matching referrer is data, not an incident. 4. Bound the work: cap how many candidates you will fetch, so the index cannot become a lever on your deploy path. Step 2's second half — which identities to accept — is a policy question with its own depth, and the honest short answer in an interview is that "a valid signature" is meaningless without "by whom": a signature that verifies against a key or identity you never intended to trust is exactly as worthless as no signature at all. ## The one-line version Discovery tells you where to look. It never tells you what to believe. Any control whose decision is reached before a cryptographic check has happened is a control an attacker can satisfy by pushing.