frontdoor rule · FD010
Org-wide GitHub subject: repo:org/* trusts every repo
Org-wide subject
Severity: high.
What it means
The subject condition matches every project in an organization rather than one project:
"StringLike": { "token.actions.githubusercontent.com:sub": "repo:acme/*" }This usually starts as convenience — several repositories need the same role, and one wildcard is shorter than five conditions. The problem is what the wildcard covers in six months rather than today.
What an attacker does
Gets write access to any single repository in the organization, or gets one created. In most organizations, creating a repository is not a privileged action and creates no alert. A new repository inherits this access the moment it exists.
The same applies to a repository transferred in from elsewhere, or a fork brought into the org.
How to fix it
Name the projects. If several share the role, list each subject:
"StringEquals": {
"token.actions.githubusercontent.com:sub": [
"repo:acme/api:ref:refs/heads/main",
"repo:acme/web:ref:refs/heads/main"
]
}If the list would be long, that is a signal the role is doing too many jobs. Give each project its own role — they almost certainly do not need identical permissions.
GCP: bind attribute.repository rather than attribute.repository_owner.
Azure: add one federated credential per subject rather than widening a single one with a claims-matching expression.
When this is deliberate
Sometimes it is: a monorepo org where every repository is equally trusted, or a role that only reads a public artifact bucket. If so, suppress it with a reason so the next person knows it was a decision:
FD010 arn:aws:iam::111122223333:role/ci-read # all repos may read artifacts, reviewed 2026-09frontdoor answers this once, when you run it; Secorvia checks it continuously across every account you connect, on a free tier that needs no card.