ferkakta.dev

Your CI/CD dispatch token can rewrite your infrastructure code

I built a cross-repo auto-deploy pipeline this week. Three app repos push Docker images to ECR, then dispatch a deploy event to the infra repo’s orchestrator workflow via repository_dispatch. Standard pattern.

The gotcha: fine-grained PATs need contents:write to call the repository_dispatch API. Not actions:writecontents:write. The permission that also lets you push code, create branches, and delete files.

My service token that should only be able to say “hey, deploy this” can also rewrite the deployment workflow it’s triggering. That’s not least privilege. That’s a door that’s three sizes too wide.

Same problem exists for workflow_dispatch.

Why it works this way

GitHub’s fine-grained PAT permission model was mapped onto an API surface designed for classic tokens with coarser scopes. repository_dispatch lives under the Repos API, not the Actions API, so it inherited the contents permission. That made sense when tokens were either “repo” or “nothing.” It doesn’t make sense when you can pick individual permissions.

The timing

Yesterday GitHub shipped return_run_details on the workflow_dispatch API — you can now get the run ID back instead of polling for it. They’re clearly investing in this surface. So here’s the ask: while you’re in there, give us a dispatches:write permission (or even just events:write) that covers repository_dispatch and workflow_dispatch without granting code access.

The workaround

Scope the PAT to a single repo. This limits the blast radius — the token can push code to the infra repo but not to every repo in the org. But “scope the blast radius of the permission you shouldn’t need” is not the same as “grant the right permission.”

Who this affects

Anyone doing cross-repo CI/CD orchestration — which is everyone with a microservices architecture and separate app/infra repos. If you have app repos dispatching to an infra repo for deployment, your dispatch token has write access to your infrastructure-as-code. That’s a supply chain risk that exists purely because of permission granularity.

#github-actions #ci-cd #security #aws