> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/edges/github/gh_in_team.md).

# GH\_IN\_TEAM

## Summary

|                              |                  |
| ---------------------------- | ---------------- |
| **Forestall ACL Alias**      | GH\_IN\_TEAM     |
| **Edge Type**                | Relationship     |
| **Affected Object Types**    | GitHub Teams     |
| **Exploitation Certainty**   | N/A (structural) |
| **GitHub Role / Permission** | Team membership  |

## Description

`GH_IN_TEAM` is a **structural membership** relationship recording that something is inside a team (bottom-up). It covers two cases:

* **(GHUser)-\[GH\_IN\_TEAM]->(GHTeam)** — a user is a member of the team.
* **(GHTeam)-\[GH\_IN\_TEAM]->(GHTeam)** — a child (nested) team belongs to its parent team.

Membership is how access flows downward: a member inherits the access the team has been granted (its repositories via `GH_HAS_ACCESS`, and anything the parent team can reach). So while `GH_IN_TEAM` is structural rather than a privilege in itself, it is a key **inheritance** hop in attack paths — compromising a member yields the team's access, and a nested team inherits its parent's grants.

The ability to *manage* team membership is a separate, privileged edge (`GH_MAINTAINER`); `GH_IN_TEAM` only records the membership itself.

## Identification

### GitHub Web Interface

Open the organization → **Teams** → a team → **Members** (users) and the team's nested-team hierarchy.

### GitHub CLI

```bash
# members of a team
gh api "orgs/{org}/teams/{team_slug}/members" --paginate --jq '.[].login'
# nested (child) teams of a team
gh api "orgs/{org}/teams/{team_slug}/teams" --paginate --jq '.[].slug'
```

## Exploitation

Not applicable on its own — `GH_IN_TEAM` is structural. Its security relevance is as an inheritance hop: a member reaches everything the team can (see `GH_HAS_ACCESS`, `GH_ADMIN`, `GH_PUSH_TO_DEFAULT`), and a child team inherits its parent's access.

## Mitigation

1. **Keep teams scoped and memberships reviewed** — a member inherits all of the team's repository access, so over-broad teams widen everyone's reach.
2. **Use shallow, intentional nesting** — child teams inherit parent access; deep hierarchies make effective access hard to reason about.
3. **Audit membership of privileged teams** (those holding admin/write on sensitive repositories) regularly.

## Detection

| Event                                    | Description                                |
| ---------------------------------------- | ------------------------------------------ |
| `team.add_member` / `team.remove_member` | A user joined / left a team                |
| `team.create` / nested-team change       | A team or nested-team relationship changed |

Alert on additions to teams that hold privileged repository access.

## References

* <https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams>