GH_HAS_ACCESS

Summary

Forestall ACL Alias	GH_HAS_ACCESS
Edge Type	Relationship
Affected Object Types	GitHub Repositories
Exploitation Certainty	N/A (structural)
GitHub Role / Permission	Any team repository permission (pull / triage / push / maintain / admin)

Description

GH_HAS_ACCESS is a structural relationship recording that a team has been granted access to a repository, together with the permission level the team holds. The level is stored on the edge as the Permission property: pull, triage, push, maintain, or admin.

This edge captures all team-to-repository access regardless of level — it answers "which teams can reach this repository, and how much access do they have?". It is the foundation that other, privileged edges are derived from:

• A team with admin also gets the GH_ADMIN attack-path edge.

• A team with push/maintain on an unprotected default branch also gets the GH_PUSH_TO_DEFAULT attack-path edge.

Because team membership flows to users via GH_IN_TEAM, this edge is how a user ultimately inherits repository access through their teams. As a structural relationship it is not itself a traversable attack path — it describes the access graph that the attack-path edges are computed over.

Identification

GitHub Web Interface

1. Open the repository → Settings → Collaborators and teams.

2. The Teams section lists every team with access and its role (Read / Triage / Write / Maintain / Admin).

GitHub CLI

List teams with access to a repository and their permission:

gh api "repos/{org}/{repo}/teams" --paginate \
  --jq '.[] | {slug: .slug, permission: .permission}'

List the repositories a team can access:

gh api "orgs/{org}/teams/{team_slug}/repos" --paginate \
  --jq '.[] | {repo: .full_name, permission: .role_name}'

Exploitation

Not applicable — this is a structural relationship, not a traversable attack path. The security-relevant capabilities derived from team access are exploited through the privileged edges built on top of it (GH_ADMIN, GH_PUSH_TO_DEFAULT).

Mitigation

1. Grant teams the least sufficient permission. Prefer read/triage over write, and reserve admin for the few teams that genuinely administer the repository.

2. Review team access periodically. Remove teams that no longer need a repository, and downgrade over-permissioned grants. Pay particular attention to teams with admin or maintain on repositories holding secrets or cloud federation.

3. Use nested teams deliberately. Child teams inherit parent access; keep the hierarchy shallow and intentional so access is easy to reason about.

Detection

Event	Description
team.add_repository	A team was granted access to a repository
team.remove_repository	A team's access to a repository was removed
team.update_repository_permission	A team's permission level on a repository changed

Alert on grants of admin/maintain to teams on sensitive repositories, and on permission escalations performed outside an approved change process.

References

• https://docs.github.com/en/rest/teams/teams#list-team-repositories

• https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization