Eine GitHub App bekommt ihre Berechtigungen nicht beim Entwickeln, sondern beim Installieren. Genau dieser Moment entscheidet, wie viel eine App später in deinen Repositories darf, und genau dieser Moment wird in der Praxis am seltensten bewusst geprüft.
Wer der Installation zustimmt
Jede Installation einer GitHub App auf einer Organisation oder einem persönlichen Account braucht eine Zustimmung. Bei einer Organisation legt eine eigene Einstellung fest, wer eine Installation genehmigen darf: in der Grundeinstellung sind das die Organisationsinhaber (Owner), eine separate Richtlinie regelt, ob auch Mitglieder oder externe Mitarbeitende eine Installation überhaupt anfragen dürfen. Diese Zustimmung ist kein Formalschritt. Sie ist der Punkt, an dem du festlegst, ob eine App Zugriff auf ein einzelnes Repository bekommt oder auf viele.
Repository-Auswahl statt All-Repositories
Bei der Installation wählst du zwischen zwei Modi: „All repositories“ (Zugriff auf alle Repositories der Organisation) oder „Only select repositories“ (du wählst einzelne Repositories aus). Für produktive Einsätze gehört die granulare Auswahl zum Standard. Eine App, die nur einen Build-Trigger in einem Repository braucht, bekommt keinen Zugriff auf die restlichen Repositories der Organisation. Jedes zusätzliche Repository in der Installation ist zusätzliche Angriffsfläche, unabhängig davon, wie vertrauenswürdig die App aktuell wirkt.
Permission-Set pro Ressource
Eine GitHub App deklariert ihre gewünschten Berechtigungen ressourcenweise, getrennt zum Beispiel für Contents, Issues, Pull Requests oder Metadata, und jede Ressource einzeln mit Lesezugriff oder Schreibzugriff. Das ist der entscheidende Unterschied zu einem klassischen Zugriff über ein Nutzerkonto: Du vergibst nicht „Zugriff auf das Repository“, sondern „Lesezugriff auf Contents“ oder „Schreibzugriff auf Pull Requests“, und sonst nichts. Ein Permission-Set für eine App, die nur CI-Status meldet, kann so aussehen:
{ "default_permissions": { "contents": "read", "checks": "write", "metadata": "read" }, "default_events": ["push", "pull_request"]}
Jede Zeile in diesem Set ist eine bewusste Entscheidung. „Contents: Read“ statt „Contents: Read & write“ bedeutet: Die App kann Code lesen, aber nicht committen. Ob ein zusätzliches Recht wirklich gebraucht wird, klärst du an dieser Stelle vor der Installation, nicht erst, wenn die App bereits läuft.
Installation Access Tokens: kurzlebig statt dauerhaft
Nach der Installation arbeitet die App nicht mit einem statischen Secret, sondern lässt sich bei Bedarf ein Installation Access Token ausstellen. Dieses Token ist standardmäßig eine Stunde gültig und läuft danach automatisch ab. Eine neue Anfrage erzeugt ein neues Token mit denselben, vorher festgelegten Grenzen, nicht mehr. Der Aufruf läuft über POST /app/installations/{installation_id}/access_tokens und braucht im Authorization-Header ein mit dem App-Private-Key signiertes JWT nach dem Bearer-Schema, nicht den gewöhnlichen gh-Nutzer-Login:
curl -X POST \ -H "Authorization: Bearer <APP_JWT>" \ -H "Accept: application/vnd.github+json" \ https://api.github.com/app/installations/<INSTALLATION_ID>/access_tokens \ -d '{"repository_ids":[123456]}'
Mit dem Feld repository_ids (bis zu 500 Repositories) lässt sich der Gültigkeitsbereich eines einzelnen Tokens sogar noch enger fassen als die Installation selbst, falls die Installation mehrere Repositories umfasst; mit permissions zusätzlich die Rechte. Ein Token kann dabei nie mehr Repositories oder Rechte erhalten, als die Installation selbst besitzt. Das Ergebnis ist ein Zugang, der von selbst verfällt, wenn niemand ihn erneuert, und der nie länger lebt als für die gerade laufende Aktion nötig.
Was dieser Beitrag nicht behandelt
Vier eng verwandte Themen gehören nicht in diesen Beitrag:
Was mit einem Maschinenkonto passiert, das dauerhaft und ohne Ablaufdatum Zugriff hält, behandelt Service-Accounts und Bot-Tokens in GitHub, 12.08.2026.
Wie sich ein schlüsselbasierter Zugriff über Deploy Keys von einer App-Identität unterscheidet, behandelt Deploy Keys oder GitHub Apps, 14.08.2026.
Wie du granulare Personal Access Tokens für dein eigenes Nutzerkonto einrichtest, behandelt Fine-grained Personal Access Tokens: Was du für dein GitHub-Nutzerkonto ändern solltest, 21.09.2026.
Der nachträgliche Scope-Review bereits installierter Apps ist ein eigenes Thema: OAuth-Scopes installierter GitHub Apps: nie wieder geprüft?, 17.09.2026. Dieser Beitrag deckt ausschließlich den Installationszeitpunkt ab, nicht die Frage, ob eine App Monate später noch die Rechte braucht, die sie einmal bekommen hat.
Was du bei der nächsten Installation konkret prüfst
Vor jeder Installation einer GitHub App in deiner Organisation lohnen sich drei Fragen: Welche Repositories braucht die App wirklich, nicht welche könnte sie theoretisch brauchen? Welche Permission-Stufe pro Ressource reicht aus, Read oder Read & write? Und wer in deinem Team sieht die Zustimmung zur Installation, bevor sie passiert? Diese drei Antworten bestimmen, was im Fehlerfall maximal exponiert ist, nicht die Qualität des Codes der App selbst.
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.
Kommentar verfassen