Dein Blog zum Thema digitales Business

Eine Installation ist eine einmalige Entscheidung, der Zugriff bleibt dauerhaft

Ein Chat-Bot für Pull-Request-Benachrichtigungen, ein Analytics-Tool für Commit-Statistiken, ein CI-Dashboard, das den Build-Status visualisiert: Bei der Installation einer solchen GitHub- oder OAuth-App zeigt dir GitHub einen Freigabedialog mit den angeforderten Berechtigungen. Du bestätigst einmal, und die App ist eingebunden. Diese eine Entscheidung ist danach in aller Regel die letzte. Niemand trägt die Installation in einen Kalender ein, niemand setzt ein Wiedervorlage-Datum. Die App behält den Zugriff, den sie an Tag eins bekommen hat, unabhängig davon, ob das Projekt noch existiert, ob die Person, die installiert hat, noch im Unternehmen ist, oder ob der Anbieter der App zwischenzeitlich den Besitzer gewechselt hat.

Was bei der Installation tatsächlich freigegeben wird

Zwei technisch unterschiedliche Mechanismen stehen hinter dem, was umgangssprachlich als „GitHub-App verbinden“ bezeichnet wird. Klassische OAuth-Apps arbeiten mit groben Scopes: Der Scope repo etwa bündelt Lese- und Schreibzugriff auf alle Repositories, auf die der autorisierende Nutzer Zugriff hat, öffentliche wie private, in einem einzigen Flag. GitHub Apps lösen das feiner auf, mit einzelnen Berechtigungen für Bereiche wie Contents, Issues, Pull Requests oder Administration, jeweils in den Stufen kein Zugriff, Lesen oder Schreiben, dazu eine explizite Auswahl, ob die App auf alle Repositories der Organisation zugreift oder nur auf ausgewählte. Trotz der feineren Aufteilung bleibt das Ergebnis dasselbe: Die Berechtigung ist einmal vergeben und läuft nicht ab. GitHub weist in der eigenen Dokumentation zu autorisierten OAuth-Apps ausdrücklich darauf hin, dass Nutzer ihre autorisierten Anwendungen überprüfen sollten, um sicherzustellen, dass keine Apps mit weitreichenden Berechtigungen autorisiert sind, etwa solche mit Zugriff auf private Repositories.

Wo sich das nachträglich nachvollziehen lässt

Zwei Ebenen sind dafür relevant. Auf der persönlichen Ebene findest du unter den eigenen Account-Einstellungen, im Bereich Integrationen unter „Applications“, zwei getrennte Reiter: „Authorized OAuth Apps“ und „Authorized GitHub Apps“. Dort lässt sich jede Anwendung einzeln widerrufen, oder über „Revoke all“ komplett zurücksetzen. Für ein Unternehmens-Repository ist die Organisationsebene die relevantere: In den Organisations-Einstellungen findet sich in der Seitenleiste der Abschnitt „Third-party Access“. Der Unterpunkt „GitHub Apps“ listet jede installierte App mit ihren Berechtigungen und dem gewährten Repository-Zugriff auf, dort lässt sich der Zugriff auf einzelne Repositories einschränken oder die App suspendieren beziehungsweise vollständig entfernen. Der Unterpunkt „OAuth app policy“ steuert, ob Organisationsmitglieder eigenständig neue OAuth-Apps für die Organisation autorisieren dürfen oder ob das die Zustimmung eines Owners braucht. Für Organisationen mit vielen Repositories und Apps stellt GitHub zusätzlich eine REST-API bereit, über die Owner die installierten Apps samt Berechtigungen und Repository-Zugriff programmatisch auslesen können, statt jede App einzeln im Web-Interface zu öffnen.

Warum die Ausweitung unauffällig bleibt

Dieses Thema ist bewusst von mehreren benachbarten Fragen abgegrenzt. Es geht hier nicht um Actions-Workflow-Berechtigungen, also den permissions-Block in einer Workflow-Datei, der vor jedem einzelnen Lauf greift und an anderer Stelle in dieser Serie behandelt wurde. Es geht auch nicht darum, ob eine Action vor ihrem ersten Einsatz überhaupt vertrauenswürdig genug ist, dazu ein eigener Beitrag. Und es geht nicht um Maschinen-Accounts ohne Person dahinter. Es geht um bereits installierte Drittanbieter-Integrationen mit dauerhaftem Zugriff auf Repository- oder Organisationsebene, und um die Frage, warum genau dieser Zugriff so selten erneut geprüft wird. Ein Grund ist strukturell: Wenn ein Anbieter seine App um eine neue Funktion erweitert, verlangt das häufig eine erneute Autorisierung mit zusätzlichen Berechtigungen, die dann von irgendeinem Organisationsmitglied bestätigt wird, ohne dass die übrige Organisation davon erfährt. Ein zweiter Grund ist personell: Die Person, die eine App ursprünglich installiert hat, ist über die Zeit nicht mehr zwingend die Person, die für den Bestand an Integrationen zuständig ist, und ein Ausscheiden aus dem Unternehmen ändert an der einmal erteilten App-Berechtigung nichts von selbst.

Riskante Scopes und ein Rhythmus, der zum Bestand passt

Nicht jede installierte App verdient dieselbe Aufmerksamkeit. Am schwersten wiegen Berechtigungen, die Repository-Inhalte schreibend verändern können, Administration-Rechte, die Branch-Protection-Regeln oder Collaborator-Listen anfassen können, sowie der Unterschied zwischen einem auf ausgewählte Repositories begrenzten Zugriff und dem Zugriff auf alle Repositories der Organisation einschließlich privater. GitHub selbst schreibt keinen festen Prüfrhythmus vor, das Sicherheitshinweis-Format der eigenen Dokumentation bleibt bewusst allgemein. Sinnvoll ist deshalb ein Anlass, der nicht vom Zufall abhängt: ein fester Termin im Kalender, unabhängig davon, ob gerade etwas auffällt, ergänzt um einen Auslöser bei jedem Rollenwechsel im Team und bei jeder Meldung über neu angeforderte Berechtigungen einer bereits installierten App. Ohne einen solchen Anlass bleibt die einzige verlässliche Gelegenheit zur Prüfung der Moment, in dem etwas bereits schiefgelaufen ist.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de