Whose Signature You Accept

## The one-sentence model A signature is a statement of the form: *this identity vouches for these exact bytes*. That is the whole payload. It is worth holding this next to its two neighbours, because mixing them up is the single most common wrong answer in supply chain interviews: | Artifact | Question it answers | |---|---| | SBOM | What is inside this artifact? | | Provenance | How did this artifact come to be? | | Signature | Who vouches for these bytes? | A signature therefore cannot tell you the artifact is safe, cannot tell you what is in it, and cannot tell you it is the artifact you meant to deploy. It tells you who put their name on it — and only if you actually read the name. ## What a presence-only check accepts A policy that verifies 'a valid signature exists' is checking two things: that the signature is cryptographically well formed over the artifact, and that the signer's credential chains to something in the verifier's trust root. Both can be true for a signature made by a total stranger. That mattered less in the era where signing meant a long-lived private key that a handful of people held, because the trust root was a short list of keys you had personally enrolled. Identity-based (keyless) signing changed the shape of the problem: the trust root becomes a public certificate authority that will issue a short-lived signing certificate to anyone who can authenticate to a supported identity provider. Membership in that trust root is no longer a meaningful authorisation signal, because effectively anyone on the internet is a member. What distinguishes your build from an attacker's build is not *whether* a certificate was issued but *to whom* — the identity recorded in it. So the concrete failure looks like this. An attacker publishes an image to a registry you pull from, signs it with their own valid identity, and your gate accepts it because the signature verifies. Nothing was forged. Nothing was cracked. The policy simply never asked the question that would have failed. ## What an acceptance rule has to name A real rule names the expected signing identity, and an identity in this world is a pair: the issuer that attested it, and the subject it attested. For a build running on a hosted CI platform, the subject is typically a URI identifying the repository, the workflow file, and the ref that ran — something shaped like `https://github.com/acme/checkout/.github/workflows/release.yml@refs/heads/main`. The rule says: accept a signature only when it came from *that* issuer over *that* subject. Scope matters as much as precision. The identity should be scoped to the artifact: the workflow that builds the checkout service should not be able to sign the payments service. A single blanket identity accepted for everything reintroduces the same problem one level up — you have checked *who*, but the *who* covers far more than the thing in front of you. ## Is presence-only verification worthless, then? Not quite, and it is worth being precise about what it is worth. Presence proves the bytes were not modified after the signature was made, and it gives you an identity to look up afterwards when something goes wrong. That makes it useful telemetry. It is not an authorisation decision, because it stops nothing an attacker who can sign for themselves wants to do. Presenting it as a control — to a customer, an auditor, or your own leadership — overstates it. The same reasoning explains why 'we sign all our artifacts' is a weaker claim than it sounds. Signing without verification changes nothing at all; verification without a named expected signer changes very little. The value appears only at the point where a consumer refuses an artifact because the identity that signed it was not the one they expected. ## The misreadings to avoid The first is treating 'signed' as a boolean property of the artifact, like 'compressed'. It is not a property of the artifact; it is a relationship between an artifact and an identity, and the identity is the half that carries the security meaning. The second is assuming that only insiders can obtain a signing identity — self-service issuance makes that false by design. The third is sliding from 'the signature is valid' to 'the build was authorised', which is exactly the inference the missing identity check was supposed to license.