frontdoor rule · FD010

Org-wide GitHub subject: repo:org/* trusts every repo

Org-wide subject

Amazon Web Services, Google Cloud, Microsoft AzureUpdated Source on GitHub

Severity: high.

What it means

The subject condition matches every project in an organization rather than one project:

jsonc
"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:

jsonc
"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:

text
FD010  arn:aws:iam::111122223333:role/ci-read   # all repos may read artifacts, reviewed 2026-09

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.