Eine Rolle, die in Zugriffsaudits gern durchrutscht
Wer ein Berechtigungskonzept für eine GitHub-Organisation dokumentiert, führt meistens zwei Spalten: Organisationsmitglied und Organisationsinhaber (Owner). Dazwischen liegt eine dritte Rolle, die in dieser Tabelle regelmäßig fehlt, weil sie an keinem der beiden Enden sitzt: der Team Maintainer. Er ist kein normales Mitglied mehr, weil er administrative Eingriffe am eigenen Team vornehmen kann. Er ist aber auch kein Organisationsadmin, weil seine Reichweite strikt auf die Teams begrenzt ist, in denen er diese Rolle trägt. Genau diese Zwischenstufe wird in Access Reviews oft übersehen, weil die Prüfung nach den zwei bekannten Extremen sucht und nicht nach einer Rolle, die irgendwo dazwischen liegt.
Was ein Team Maintainer am eigenen Team ändern darf
Laut GitHub-Dokumentation zur Team-Maintainer-Rolle kann jedes Teammitglied zum Maintainer gemacht werden, ausschließlich durch einen Organization Owner; die Person muss davor bereits Mitglied des Teams sein. Die Rolle selbst bringt eine klar aufgezählte Liste an Rechten mit, bezogen auf das eigene Team:
- Name und Beschreibung des Teams ändern
- Sichtbarkeit des Teams ändern
- Ein Kind-Team anfordern
- Ein Eltern-Team anfordern oder wechseln
- Das Profilbild des Teams setzen
- Organisationsmitglieder zum Team hinzufügen
- Organisationsmitglieder aus dem Team entfernen
- Die Maintainer-Rolle an andere Teammitglieder vergeben
- Den Zugriff des Teams auf Repositories entfernen
- Die Code-Review-Zuweisung für das Team verwalten
- Geplante Erinnerungen für Pull Requests verwalten
Das deckt den Punkt, den Audits meistens unterschätzen: Ein Maintainer verwaltet nicht nur Mitglieder. Er kann auch anderen Mitgliedern dieselbe Maintainer-Rolle geben, ohne dass dafür erneut ein Organization Owner gebraucht wird. Wer ein Team einmal einem Maintainer übergibt, gibt damit auch die Kontrolle darüber ab, wer in diesem Team künftig mitredet.
Repo-Zugriff: zwei Wege, eine Verwechslungsgefahr
Hier liegt der Punkt, der in der Praxis am häufigsten zu falschen Annahmen führt. GitHub kennt zwei unterschiedliche Stellen, von denen aus der Zugriff eines Teams auf ein Repository verändert wird, und beide haben unterschiedliche Rollen-Voraussetzungen.
Von der Team-Seite aus (Organisation, Teams, eigenes Team, Reiter Repositories) gilt laut Dokumentation zu Teams: „Organization owners and team maintainers can give teams admin, read, or write access to organization repositories.“ Ein Maintainer kann seinem eigenen Team hier tatsächlich eine neue Berechtigungsstufe für ein Repository zuweisen, ohne dafür zusätzlich Admin-Rechte auf diesem Repository zu benötigen.
Von der Repository-Seite aus (Repository, Settings, Collaborators and teams) gilt eine andere Regel: „People with admin access to a repository can manage team access to the repository.“ Diese zweite Tür verlangt Admin-Zugriff auf genau dieses Repository, unabhängig von einer Maintainer-Rolle in irgendeinem Team.
Beim direkten Entzug ist die Dokumentation eindeutig auf den Maintainer gemünzt: „Team maintainers can remove a team’s access to a repository if the team has direct access to it.“ Bei vererbtem Zugriff über ein Eltern-Team endet die Reichweite des Maintainers an genau dieser Stelle: Er kann die Berechtigung des Kind-Teams auf den Wert des Eltern-Teams zurücksetzen, aber nicht eigenständig ändern. Eine eigenständige Änderung ist laut Dokumentation nur am Eltern-Team selbst möglich: „If the team’s access to the repository is inherited from a parent team, you must change the parent team’s access to the repository.“ Wer einem Maintainer vertraut, weil „der kann doch nur sein eigenes Team verwalten“, sollte vorher geklärt haben, ob dieses Team Repositories direkt hält oder nur über ein Eltern-Team erbt. Der Unterschied entscheidet darüber, wie weit dieser eine Klick tatsächlich reicht.
Die Grenze zum Organisationsadmin
Ein Organization Owner hat laut Dokumentation „complete administrative access to your organization“ und sollte laut Empfehlung auf nicht weniger als zwei Personen verteilt sein, aber auch nicht beliebig breit. Ein Team Maintainer erreicht diese Reichweite an keiner Stelle. Zwei Grenzen sind dabei für ein Access Review besonders relevant.
Erstens: Required Reviewers und andere Branch-Protection-Regeln liegen außerhalb der Maintainer-Rolle. Laut Dokumentation zu geschützten Branches können diese Regeln nur „Repository administrators or custom roles with the ‚edit repository rules‘ permission“ festlegen. Team Maintainer taucht in dieser Aufzählung nicht auf. Ein Maintainer kann also, wie oben gezeigt, einem Team Schreibzugriff auf ein Repository geben, aber er kann auf diesem Repository keine Regel setzen, die zum Beispiel zwei Freigaben vor dem Merge erzwingt, es sei denn, er trägt auf diesem konkreten Repository zusätzlich eine Admin-Rolle oder eine passende benutzerdefinierte Rolle.
Zweitens: organisationsweite Einstellungen wie neue Mitglieder zur gesamten Organisation einladen, Abrechnung verwalten oder Sicherheitsrichtlinien für alle Repositories setzen, bleiben Owner-Territorium. Der Maintainer wirkt immer nur innerhalb der Teams, in denen er diese Rolle trägt, nie auf die Organisation als Ganzes.
Abgrenzung zu zwei früheren Beiträgen
Im Beitrag GitHub Onboarding Berechtigungen vom 26.09.2026 ging es um die Zeitachse: wann im Onboarding-Prozess ein neues Mitglied welchem Team zugewiesen wird. Hier geht es um etwas anderes, um die Rollen-Governance-Stufe selbst, unabhängig davon, zu welchem Zeitpunkt sie vergeben wird. Ein Team Maintainer bleibt Team Maintainer, ob er am ersten Arbeitstag oder nach zwei Jahren in diese Rolle gehoben wird.
Im Beitrag Effektive vs. nominale Rechte in GitHub: warum Team-Vererbung überrascht vom 15.07.2026 ging es um die Vererbungsmechanik selbst, also wie sich Rechte über mehrere Teams hinweg addieren und warum die effektive Berechtigung einer Person oft höher ausfällt als die nominale. Hier geht es nicht um die Addition von Rechten einer Person, sondern um die Maintainer-Rolle als eigene Governance-Stufe: eine Person, die mehr kann als ein normales Mitglied, aber klar weniger als ein Owner, und die in einer Rollentabelle eine eigene Zeile braucht, statt in einer der beiden bekannten Spalten mitgezählt zu werden.
Was das für dein Access Review heißt
Eine Rollentabelle, die nur „Mitglied“ und „Owner“ kennt, hat strukturell eine Lücke. Wer ein Access Review durchführt, dokumentiert für jedes Team einzeln, wer dort Maintainer ist, und wer wiederum anderen diese Rolle verliehen hat, denn diese Weitergabe läuft ohne erneute Owner-Freigabe. Zusätzlich lohnt sich die Prüfung, welche Repositories ein Team direkt hält und welche nur über ein Eltern-Team vererbt sind, weil genau dieser Unterschied bestimmt, wie weit ein einzelner Maintainer-Klick tatsächlich reicht, und ob ein Maintainer auf einem konkreten Repository zusätzlich Admin-Rechte trägt, die ihm Branch-Protection-Änderungen erlauben, die seine Teamrolle allein nicht hergibt.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen