frontdoor rule · FD011
GitHub OIDC role assumable from any branch or tag
No branch or ref restriction
Severity: high.
What it means
The subject pins the repository but not the ref, so a workflow on any branch or tag can assume the role:
repo:acme/api:*Only fired for platforms where a ref is a real concept — GitHub, GitLab,
Buildkite. Flagging "no ref restriction" on a platform without refs would be
noise, so frontdoor does not.
What an attacker does
Pushes a branch. Anyone with write access to the repository can do that without review, and so can a compromised contributor account, a leaked personal access token, or a malicious dependency in a workflow that has push rights.
Branch protection on main does not help: the point of this finding is that
the trust does not care which branch ran.
How to fix it
Prefer a deployment environment over a ref. Environments carry required reviewers and survive branch renames:
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:acme/api:environment:production"
}Or pin the ref and protect that branch:
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:acme/api:ref:refs/heads/main"
}Pinning the ref without protecting the branch achieves very little — anyone who
can push to main can still use the role.
Tags are worth a thought: refs/tags/* is often used for release pipelines,
and tags are frequently less protected than branches.
When this is deliberate
A role that only pushes build artifacts, where any branch legitimately builds. Suppress with the reason.
frontdoor answers this once, when you run it; Secorvia checks it continuously across every account you connect, on a free tier that needs no card.