Your deploy policy accepts any signature from an identity inside your GitHub organisation — what is wrong?

## Why teams write the org-wide rule Nobody sets out to trust an intern's sandbox. The rule usually starts life as a migration convenience: dozens of services, each with its own repository and workflow layout, and one platform team trying to turn verification on this quarter. A single pattern covering the whole organisation makes every service pass on day one and nobody is blocked. It also looks defensible in a slide — 'we only accept artifacts signed by identities inside our own organisation' is a sentence that sounds like a control. The second reason is brittleness avoidance. A precisely named identity breaks when a repository is renamed, a workflow file moves, or a release starts running from a tag instead of a branch. An org-wide pattern never breaks. That property is not a feature; it is the policy telling you it is not checking anything specific. ## What the organisation actually contains Work through the set the rule admits. Every repository in the org, including sandboxes, spikes, archived projects and the repository someone created to test a webhook. Every workflow file inside each of them, not just release workflows. Every ref those workflows can run from, including a branch pushed five minutes ago. Anywhere the org's CI can run with the ability to request a signing identity, an artifact can be produced that satisfies the rule. So the practical threat is not the anonymous internet attacker; it is the authenticated low-privilege insider — a contractor, a new joiner, an intern with write access to one unwatched repository, or anyone who compromises such an account. They do not need to touch the checkout repository, get a review approved, or defeat any branch protection on the production release path. They write a workflow in their own repository, build an image, sign it with an identity that is genuinely inside the org, push it where the deploy path will pick it up, and the gate says yes. The asset at risk is the availability and revenue of the checkout path, and the control that was supposed to protect it reported green throughout. ## Nothing is broken, which is the point It is worth saying plainly in an interview: no cryptography failed, no key leaked, no certificate authority misbehaved. The signature is valid and the identity is real. The defect is entirely in the acceptance rule's granularity — it expressed a much larger set than the one the author had in mind. This is why 'we verify signatures' is never a sufficient answer to 'what do you accept?'. The interesting content of a signing programme lives in the identity set, not in the verification step. ## Tightening it The target granularity is per-artifact: for each artifact you deploy, name the repository, the workflow file that releases it, and the ref that workflow is allowed to run from — together with the expected issuer. The checkout image is accepted only from the checkout release workflow. The payments image is accepted only from the payments release workflow. Cross-signing between them is not possible, so compromising one service's build does not yield the ability to ship any other. Two scale objections come up, and both have answers: **'That is hundreds of rules.'** Generate them. The mapping from artifact to producing identity already exists somewhere — a service catalogue, the deployment definitions, the release tooling — and a generated policy stays correct as services are added. A hand-maintained list is what decays into a wildcard. **'Renames will break production.'** They will, and that is a release-process problem rather than a policy problem. Route releases through a small number of shared, reusable release workflows so the identity surface is small and stable on purpose; then treat a change to the identity string like a schema migration — it ships in the same change as the rename, not afterwards. When a rename does slip through and every verification fails at once, widening the expected identity to a wildcard is the worst option on the table: it is a permanent loosening bought to end a temporary outage, and it never gets tightened again. Roll the rename back, re-release under the new identity, or add the new literal identity beside the old one with a dated removal. ## The same mistake one level out The org-wide rule has a cousin worth recognising: a managed-service vendor that builds and signs deliverables for many customers under a single shared identity. Accepting that identity is not wrong in the way an org wildcard is wrong — you did name a specific signer — but it still cannot express what you need, because one identity covers every tenant's artifact. A malicious co-tenant who can get the vendor's build system to produce something for them produces something your policy accepts. The remedy is the same in shape: ask for an identity scoped to your deliverables, because if the identity is coarser than the distinction you need to make, no amount of careful verification will make that distinction for you.