GitHub-Berechtigungen für Auftragnehmer müssen enden

Externe Sanierungsteams sollten die kleinste GitHub-Rolle erhalten, mit der sie die konkrete Aufgabe erledigen können. Diese Rolle braucht ein Ablaufdatum. Bei den meisten Aufträgen bedeutet das Read während der Diagnose, Write während der Reparatur, keine direkte Freigabe für die Produktion und ein kurzes Admin-Fenster nur dann, wenn eine benannte Repository-Einstellung geändert werden muss.

Eine ungenaue Bitte um „GitHub-Zugriff“ macht aus einer zweitägigen Reparatur schnell eine unbefristete Verfügungsgewalt über Quellcode, Secrets, Workflows, Releases und Repository-Einstellungen. Ich habe erlebt, wie Eigentümer Admin vergaben, weil sie nicht wussten, welche kleinere Rolle ausreichen würde. Später stellte sich heraus, dass niemand die Änderungen dokumentiert und niemand an das Entfernen des Kontos gedacht hatte. Der sichere Ablauf ist unkompliziert: Teilen Sie den Auftrag in Phasen, verbinden Sie jede Berechtigung mit einem Ergebnis, lassen Sie geschützte Branches zwischen dem Reparaturteam und der Produktion stehen und planen Sie den Entzug, bevor Sie die Einladung versenden.

Bei KI-generierten Anwendungen ist das noch wichtiger. Ein Team muss womöglich eine defekte Authentifizierung, offengelegte Secrets, SQL-Injection, verschachtelte Module und ein Deployment untersuchen, das nur vom Laptop einer einzigen Person funktioniert. Solche Probleme rechtfertigen einen genauen Zugriff auf den Code. Sie rechtfertigen nicht automatisch die Kontrolle über Abrechnung, Mitwirkende, Branch-Regeln, Webhooks, Umgebungen oder Produktionszugänge.

Berechtigungen gehören zu Aufgaben, nicht zu Titeln

GitHub-Rollen beschreiben Befugnisse, nicht Vertrauenswürdigkeit. Auch ein angesehener externer Entwickler kann mit einer zu breiten Rolle einen folgenschweren Fehler machen. Eine eng begrenzte Rolle verringert sowohl die Kosten ehrlicher Fehler als auch den Schaden durch ein kompromittiertes Konto.

GitHubs Dokumentation Repository roles for an organization ordnet die Standardrollen als Read, Triage, Write, Maintain und Admin. Die Beschreibungen sind hilfreich: Read eignet sich für Personen, die ein Projekt ansehen oder besprechen müssen. Triage ergänzt die Verwaltung von Issues und Pull Requests ohne Schreibzugriff. Write erlaubt aktive Beiträge zum Code. Maintain deckt die Verwaltung des Repositorys ohne einige sensible oder destruktive Aktionen ab. Admin gewährt vollen Zugriff. Es ist ein Fehler, diese Reihenfolge als berufliche Rangordnung zu lesen. Sie ist eine Übersicht der Fähigkeiten.

Übersetzen Sie den Auftrag in Liefergegenstände, bevor Sie jemanden zuweisen:

• Ein Diagnosebericht, ein Abhängigkeitsinventar oder eine Architekturübersicht benötigt normalerweise Read.
• Das Sortieren von Issues, die Nachverfolgung reproduzierter Fehler und die Koordination von Pull Requests können Triage erfordern.
• Reparatur-Commits und Pull Requests benötigen Write, sofern das Team nicht über einen Fork arbeitet.
• Änderungen an Branch-Regeln, Mitwirkenden, Umgebungen oder Sicherheitseinstellungen können für kurze Zeit Admin erfordern.
• Die Freigabe eines Produktions-Releases sollte bei einer internen verantwortlichen Person bleiben, auch wenn das externe Team das Release vorbereitet.

Halten Sie die Zuordnung schriftlich fest. Ein kleiner Zugriffsvertrag ist nützlicher als ein Absatz in einer Leistungsbeschreibung, weil ein Eigentümer ihn mit den GitHub-Einstellungen abgleichen kann:

repository: acme/example-app
team: external-remediation
phase_1:
  role: read
  output: diagnosis-and-repair-plan
phase_2:
  role: write
  branches: repair/*
  output: reviewed-pull-requests
admin_window:
  allowed_changes:
    - branch-protection
    - deployment-environment
  approved_by: internal-repository-owner
  ends_at: 2026-08-15T18:00:00Z
revocation_owner: engineering-director

Diese Datei setzt selbst nichts durch. Sie verhindert den häufigen Fehler, dass sich der Umfang in einem Gespräch ändert, während der Zugriff unverändert bleibt. Falls das Team eine neue Fähigkeit benötigt, aktualisieren Sie den Eintrag, holen Sie die Genehmigung ein und ändern Sie danach die Rolle.

Wenn das Repository einer Organisation gehört, fügen Sie namentlich bekannte Personen als externe Mitwirkende hinzu oder nutzen Sie eine passende Organisationsstruktur unter der Kontrolle Ihrer eigenen Administratoren. Verwenden Sie kein gemeinsames Anbieterkonto. Individuelle Identitäten machen Reviews, Audit-Ereignisse und den Entzug nachvollziehbar. Erzwingen Sie Zwei-Faktor-Authentifizierung auf Organisationsebene, wenn Ihre Konfiguration dies unterstützt, und prüfen Sie, ob jede Person die Einladung mit der eigenen Identität angenommen hat.

Read reicht für ein Audit

Ein gründliches Code-Audit braucht keinen Push-Zugriff. Mit Read auf ein privates Repository kann das Team den Code untersuchen und klonen, den Commit-Verlauf studieren, Branches prüfen und an normalen Diskussionen teilnehmen. Das deckt den ersten Durchgang der meisten Sanierungsaufträge ab.

Das Audit sollte Belege liefern, bevor jemand Code bearbeitet: eine Übersicht der Einstiegspunkte, eine Liste fehlerhafter Abläufe, eine Bewertung offengelegter Secrets, eine Prüfung von Abhängigkeiten und Build sowie eine vorgeschlagene Reihenfolge der Reparaturen. Das Team benötigt möglicherweise außerdem Lesezugriff auf verwandte Repositorys mit gemeinsam genutzten Paketen oder Infrastrukturdefinitionen. Gewähren Sie diese Repositorys ausdrücklich, statt eine breite Mitgliedschaft in der Organisation zu vergeben.

Auch Read hat Folgen. Ein Mitwirkender kann einen lokalen Klon erstellen, und der Entzug des GitHub-Zugriffs holt diese Kopie nicht zurück. GitHubs Dokumentation zur Verwaltung des individuellen Repository-Zugriffs sagt, dass das Entfernen den Zugriff beendet und private Forks in den beschriebenen Fällen löscht. Lokale Klone bleiben jedoch erhalten. Der vertragliche Umgang mit vertraulichem Quellcode, seine Löschung beim Ausscheiden und eine Liste zugelassener Geräte liegen daher außerhalb der GitHub-Rollensteuerung. Tun Sie nicht so, als würde eine Schaltfläche zum Entzug bereits kopierte Daten löschen.

Die Audit-Phase ist auch der richtige Zeitpunkt, um die Offenlegung von Secrets zu begrenzen. Read für das Repository bedeutet nicht, dass das Team Datenbankpasswörter, Cloud-Zugänge, Zahlungsschlüssel oder Kundenexporte benötigt. Secrets sollten gar nicht erst im Repository liegen. Findet das Audit einen eingecheckten Zugang, müssen Sie davon ausgehen, dass der Wert kopiert worden sein könnte. Ersetzen Sie ihn in dem System, das ihn ausgegeben hat, und nehmen Sie den alten Wert außer Betrieb. Das Umschreiben des Git-Verlaufs ohne Austausch des Zugangs korrigiert die sichtbare Spur, nicht die Offenlegung.

Read kann unzureichend werden, wenn die Diagnose von privaten Build-Protokollen, Details zu Sicherheitswarnungen oder externen Systemen abhängt. Behandeln Sie jeden solchen Bedarf als eigenen Antrag. GitHubs Rollenmatrix zeigt, dass manche Listen mit Sicherheitswarnungen erst ab Write zugänglich sind, während Ergebnisse der Codeanalyse an Pull Requests eine andere Sichtbarkeit besitzen. Erhöhen Sie nicht die gesamte Repository-Rolle, ohne die fehlende Ansicht genau zu benennen. Eine interne verantwortliche Person kann die benötigte Warnung oft exportieren, den Fehler reproduzieren oder eine Einstellung per Bildschirmfreigabe zeigen.

Ein gutes Audit endet mit einer Berechtigungsprüfung. Das Sanierungsteam sollte die zu ändernden Dateien, die geplanten Branches, die benötigten Prüfungen und alle störenden Repository-Einstellungen benennen. Erst dann sollte Read zu Write werden. Wenn der Bericht nicht erklärt, warum der Code geändert werden muss, verbessert zusätzlicher Zugriff den Bericht nicht.

Triage erlaubt keine Reparaturen

Triage eignet sich zur Verwaltung der Arbeitswarteschlange, ersetzt aber Write nicht. Die Rolle lässt einen externen Koordinator Issues, Labels, Meilensteine, Diskussionen und Teile der Pull-Request-Arbeit verwalten, ohne ihm Push-Rechte für Code zu geben.

Damit ist Triage eine sinnvolle Rolle für eine Projektleitung, die Fehler reproduziert, Duplikate entfernt, Arbeit zuweist, fehlende Nachweise anfordert und den Eigentümer informiert hält. Die Rolle hilft auch, wenn ein separates Reparaturteam über Forks beiträgt und eine externe Leitung eingehende Pull Requests organisieren muss. Sie trennt Koordination von Änderungen am Quellcode.

Teams missverstehen das Wort „Triage“ oft und nehmen an, es umfasse kleine Korrekturen. Das stimmt nicht. Muss eine Person einen Branch im privaten Repository erstellen, einen Commit pushen, einen Workflow aktualisieren oder eine genehmigte Reparatur mergen, sollten Sie Write prüfen. Wenn ein interner Entwickler immer wieder Anbieter-Patches in einen Branch kopieren muss, entstehen eine schlechte Herkunftsspur und unnötige Review-Arbeit. Halten Sie die Person entweder in einer echten Koordinationsrolle oder vergeben Sie die zur Programmieraufgabe passende Rolle.

Triage ist nicht für jeden Auditor automatisch sicherer als Read. Die Rolle erlaubt Änderungen daran, wie Arbeit dargestellt und priorisiert wird. Ein böswilliger oder unvorsichtiger Koordinator kann Issues schließen, Labels verändern oder die Review-Warteschlange stören, ohne den Quellcode anzufassen. Vergeben Sie Triage nur, wenn die Issue-Verwaltung zum Ergebnis gehört, nicht weil die Rolle nach einem Mittelweg klingt.

Verwenden Sie Triage nicht als Ersatz für einen fehlenden Prozess. Legen Sie fest, wer Sicherheitsbefunde schließen darf, wer eine Korrektur akzeptiert und wer Änderungen am Umfang kommuniziert. Ein externes Team darf einen Punkt als bereit für die interne Prüfung markieren, ohne die eigene Arbeit selbst als angenommen erklären zu dürfen. Diese Trennung hält die Aufzeichnung ehrlich, wenn der Termin drängt.

Bei einem kurzen Auftrag können Read und normale Kommentare an Pull Requests während der Diagnose genügen. Fügen Sie Triage hinzu, wenn die Menge der Befunde eine aktive Verwaltung der Warteschlange verlangt. Entfernen Sie die Rolle am Ende zusammen mit dem übrigen Repository-Zugriff, denn ein altes Koordinatorkonto legt weiterhin private Gespräche und Code offen.

Write gehört auf Reparatur-Branches

Write ist die normale Rolle für Entwickler, die Code in Ihrem Repository reparieren müssen. Sie erlaubt aktive Beiträge. Kombinieren Sie sie deshalb mit geschützten Branches, Pull-Request-Reviews, automatisierten Prüfungen und einem ausdrücklichen Verbot langlebiger gemeinsamer Zugänge.

Write sollte einen Weg eröffnen, Änderungen vorzuschlagen, nicht die Annahmekriterien neu festzulegen. Externe Entwickler können repair/*-Branches anlegen, Commits pushen, Pull Requests öffnen, auf Reviews antworten und die vorgeschlagene Korrektur aktualisieren. Interne Verantwortliche sollten Änderungen an Authentifizierung, Autorisierung, Datenmigration, Zahlungen, Build-Workflows oder Produktionsinfrastruktur genehmigen.

Die einfachste brauchbare Branch-Regelung hat vier Teile:

• Verlangen Sie Pull Requests, bevor Änderungen den Standard-Branch erreichen.
• Verlangen Sie mindestens eine interne Freigabe für Pfade mit großen Auswirkungen.
• Verlangen Sie erfolgreiche Build-, Test-, Lint- und Sicherheitsprüfungen des Repositorys.
• Blockieren Sie Force-Pushes und das Löschen geschützter Release-Branches.

Fügen Sie Code-Eigentümer für Bereiche hinzu, in denen eine scheinbar kleine Änderung Befugnisse in der Produktion verändern kann. Eine kurze Datei könnte so aussehen:

/.github/workflows/ @acme/platform-owners
/auth/ @acme/security-owners
/db/migrations/ @acme/data-owners
/infra/ @acme/platform-owners

Eine CODEOWNERS-Datei benennt Reviewer. Zu einer Schranke wird sie erst, wenn der Branch-Schutz oder ein Regelsatz ein Review durch Code-Eigentümer verlangt. Ohne diese Durchsetzung ist die Datei nur ein Hinweis zur Weiterleitung. Teams vermischen diese beiden Funktionen regelmäßig. Die Folge ist ein Pull Request, der kontrolliert aussieht, obwohl GitHub einen Merge ohne den genannten Eigentümer erlaubt.

Geben Sie dem externen Team kein gemeinsames persönliches Zugriffstoken. Jeder Entwickler sollte ein eigenes Konto verwenden. Automatisierung sollte eine eng begrenzte GitHub App oder ein Token Ihrer Organisation nutzen, wenn Automatisierung tatsächlich nötig ist. Das Entfernen von Nutzern ist viel sauberer, wenn Commits, Freigaben und API-Aktivitäten verschiedenen Akteuren zugeordnet sind.

Write kann mehr offenlegen als die reine Codeänderung. Workflow-Dateien verdienen besondere Aufmerksamkeit, weil jemand mit Änderungsrecht für einen Automatisierungs-Workflow beeinflussen kann, was auf einem Runner ausgeführt wird oder wie verfügbare Zugänge verwendet werden. Stellen Sie Workflow-Änderungen unter internes Review, begrenzen Sie die Standardberechtigungen von GITHUB_TOKEN auf den Bedarf der jeweiligen Aufgabe und betrachten Sie einen erfolgreichen Workflow nie als Beleg für die Sicherheit einer Workflow-Änderung.

Lassen Sie die Bequemlichkeit der Reparatur nicht den Verlauf löschen. Verbieten Sie Force-Pushes auf gemeinsam genutzten Reparatur-Branches, verlangen Sie eine aussagekräftige Commit-Urheberschaft und fordern Sie Erklärungen zu sicherheitsrelevanten Änderungen im Text des Pull Requests. Squashing beim Merge kann vertretbar sein, doch der Pull Request muss die Diskussion und Prüfungen bewahren, die das Ergebnis begründen.

Admin ist eine kurze kontrollierte Ausnahme

Admin sollte eine zeitlich begrenzte Ausnahme für eine benannte Einstellungsaufgabe sein, nicht die Ausgangsrolle für eine Sanierung. Die Rolle umfasst sensible und destruktive Aktionen, darunter Zugriffs- und Regelverwaltung, die für eine normale Code-Reparatur nicht erforderlich sind.

Es gibt berechtigte Fälle. Der vorhandene Branch-Schutz kann fehlen oder falsch konfiguriert sein. Eine Deployment-Umgebung braucht womöglich einen Reviewer oder eine Branch-Beschränkung. Sicherheitseinstellungen müssen vielleicht aktiviert werden. Ein Webhook oder Deployment-Schlüssel kann Teil des Fehlers sein. Je nach Funktion und Tarif erfordern einige dieser Änderungen bei den GitHub-Standardrollen Admin.

Die falsche Reaktion besteht darin, Admin für die gesamte Reparatur beizubehalten, weil mehrere Einstellungen Aufmerksamkeit verlangen könnten. Arbeiten Sie mit einem Erhöhungsfenster:

1. Die externe Leitung legt die genaue aktuelle Einstellung, die vorgeschlagene Einstellung, den Grund und den Rückweg vor.
2. Ein interner Repository-Eigentümer genehmigt die Änderung und hält Start- und Endzeit fest.
3. Ein namentlich bestimmter externer Entwickler erhält Admin, während die übrigen Teammitglieder ihre bisherigen Rollen behalten.
4. Die interne verantwortliche Person beobachtet oder prüft die Einstellungsänderung und sichert Nachweise.
5. Direkt nach der Prüfung setzt der Eigentümer den Entwickler auf Write zurück.

Ein interner Administrator kann die Änderung nach der schriftlichen Empfehlung des Teams selbst vornehmen, wenn die Einstellung einfach ist. Das geht oft schneller als die Einrichtung eines vorübergehenden Admin-Zugriffs. Externes Admin ist eher sinnvoll, wenn die Diagnose von einem komplizierten Zusammenspiel zwischen Regeln, Umgebungen, Webhooks oder Sicherheitskontrollen abhängt und die Fachperson die Konfiguration direkt untersuchen muss.

Maintain wird manchmal als harmloser Kompromiss vorgeschlagen. Die Rolle kann Teile eines Repositorys ohne alle Admin-Aktionen verwalten, ist aber immer noch breiter als ein Codebeitrag und enthält möglicherweise gerade die sensible Einstellung nicht, die zur Erhöhung geführt hat. Maintain ohne Prüfung der Fähigkeiten zu vergeben, verbindet zwei Fehler: überflüssige Befugnisse für fremde Aufgaben und keine Sicherheit, dass die benötigte Aktion funktioniert. Wählen Sie die Rolle nur, wenn ein dokumentierter Satz von Wartungsaufgaben zum Auftrag passt.

Geben Sie für die Reparatur eines Repositorys niemals den Organisations-Owner weiter. Repository-Admin und Organisations-Owner wirken in verschiedenen Bereichen. Benötigt das Team organisationsweite Informationen, kann ein Eigentümer sie exportieren, die Änderung selbst vornehmen oder in GitHub Enterprise Cloud eine unterstützte benutzerdefinierte Rolle erstellen. Eine einzige defekte Anwendung rechtfertigt keine Kontrolle über alle Repositorys und Mitglieder.

Bei Admin-Zugriff ist auch das Umgehen von Regeln wichtiger. Manche Schutzregeln lassen Administratoren passieren, sofern dies nicht anders konfiguriert wurde. Wenn Sie die Rolle einer Person vorübergehend erhöhen, prüfen Sie, ob die Regel weiter für Administratoren gilt. Die Bezeichnung „geschützt“ beantwortet diese Frage nicht.

Branch-Schutz muss den Auftrag überdauern

Geschützte Branches und Regelsätze sollten sowohl das externe Team als auch Ihre eigenen Administratoren begrenzen, wenn das Risiko dies verlangt. Ein Reparaturprozess scheitert, wenn die Branch-Schranke immer dann verschwindet, wenn jemand genügend Rechte besitzt und sie lästig findet.

GitHubs Dokumentation Managing a branch protection rule sagt, dass Regeln für geschützte Branches Pull-Request-Freigaben und erfolgreiche Statusprüfungen verlangen können. Sie weist außerdem darauf hin, dass immer nur eine Branch-Schutzregel gilt, wodurch sich überschneidende Muster schwer verständlich werden. GitHub nennt Regelsätze als Alternative. Dieses Detail ist bei einer Sanierung wichtig: Eine neue Wildcard-Regel wird möglicherweise nicht mit der erwarteten Regel kombiniert. Testen Sie die tatsächlich geltende Richtlinie auf dem echten Standard-Branch und den Release-Branches.

Beginnen Sie mit dem Standard-Branch und jedem Branch oder Tag, der deployen kann. Verlangen Sie Pull Requests, verwerfen Sie veraltete Freigaben nach wesentlichen Codeänderungen, verlangen Sie bei entsprechender Review-Praxis die Auflösung von Gesprächen und benennen Sie die Statusprüfungen, die einen fehlerhaften Build wirklich blockieren. Eine verpflichtende Prüfung, die nie läuft, kann alle Merges einfrieren. Eine Prüfung mit wechselndem Jobnamen kann unbemerkt aufhören, zur vorgesehenen Schranke zu passen. Prüfen Sie das Verhalten mit einem wegwerfbaren Pull Request.

Halten Sie Umgehungslisten kurz. Das Sanierungsteam gehört normalerweise nicht darauf. Kann eine Migration oder dringende Reparatur eine vorhandene Prüfung nicht bestehen, dokumentieren Sie, warum die Prüfung falsch oder eine kontrollierte Ausnahme nötig ist. Eine instabile Prüfung zu reparieren gehört dazu, das Repository produktionsreif zu machen. Sie bei jedem Pull Request zu umgehen, versteckt nur den Defekt.

Repository-Regeln ersetzen kein Review-Urteil. Ein grüner Build kann Syntax, Tests und konfigurierte Scanner bestätigen. Er kann nicht entscheiden, ob ein neuer Authentifizierungsablauf zur Richtlinie für die Kontowiederherstellung passt oder ob eine Datenmigration die fachliche Bedeutung erhält. Benennen Sie interne Reviewer, die diese Folgen verstehen.

Prüfen Sie die Regeln nach jedem Admin-Fenster. Vergleichen Sie die endgültige Konfiguration mit dem genehmigten Zugriffsvertrag, suchen Sie nach neuen Akteuren mit Umgehungsrecht, bestätigen Sie die Sperre von Force-Pushes und prüfen Sie, ob Code-Owner-Reviews für die vorgesehenen Pfade gelten. Sichern Sie bei Bedarf Screenshots oder exportierte Konfigurationen, aber bewahren Sie auch eine durchsuchbare Textaufzeichnung der Entscheidung auf.

Wenn FixMyMess eine KI-generierte Anwendung repariert, gilt dieselbe sinnvolle Berechtigungsgrenze wie bei jedem externen Team: genug Zugriff für Diagnose und geprüfte Änderungsvorschläge, während der Repository-Eigentümer die abschließende Kontrolle behält. Code-Diagnose, Logikreparatur, Sicherheitshärtung, Refactoring und Deployment-Vorbereitung der Plattform benötigen kein dauerhaftes Eigentum am Repository des Kunden.

Deployment-Zugriff ist eine eigene Entscheidung

Write im Repository muss nicht die Befugnis zur Freigabe eines Produktions-Deployments enthalten. Behandeln Sie Codebeiträge, Workflow-Änderungen, Umgebungsfreigaben, Cloud-Zugriff und das Lesen von Produktions-Secrets als getrennte Kontrollen.

GitHub-Deployment-Umgebungen können Reviewer verlangen, Deployment-Branches oder Tags beschränken und Umgebungs-Secrets zurückhalten, bis Schutzregeln erfüllt sind. Die Dokumentation Deployments and environments unterstützt außerdem das Verhindern eigener Freigaben. Bei aktivierter Option kann die Person, die ein Deployment gestartet hat, denselben geschützten Job nicht genehmigen. Nutzen Sie diese Trennung für externe Reparaturen: Das Team bereitet das Release vor, eine interne Person autorisiert die Produktion.

Ein sicherer Ablauf sieht so aus:

1. Der externe Entwickler öffnet einen Reparatur-Pull-Request, woraufhin alle erforderlichen Codeprüfungen laufen.
2. Interne Eigentümer prüfen sensible Pfade und mergen den genehmigten Commit.
3. Ein Deployment-Workflow verweist auf die geschützte Produktionsumgebung.
4. Ein interner Reviewer prüft Commit, Migrationsplan und Rückweg und genehmigt danach den Job.
5. Der Workflow erhält Umgebungs-Secrets erst nach Erfüllung der Schutzregeln.

Die Umgebung sollte Deployments nur vom vorgesehenen geschützten Branch oder passenden Release-Tag-Muster annehmen. Gehen Sie nicht davon aus, dass der Schutz von main automatisch jede Umgebung begrenzt. Konfigurieren und testen Sie die Deployment-Branch- oder Tag-Regeln der Umgebung.

Gehen Sie vorsichtig mit Workflow-Änderungen um. Ein Mitwirkender mit Write kann eine Änderung vorschlagen, die Auslöser, Runner-Befehle, Artefakte oder die Verwendung von Zugängen verändert. Verlangen Sie Code-Owner-Reviews für .github/workflows/, minimieren Sie die Berechtigungen des Workflow-Tokens, fixieren Sie vertrauenswürdige Actions nach Ihrer Richtlinie und prüfen Sie jede Nutzung selbst gehosteter Runner. GitHub weist darauf hin, dass selbst gehostete Runner nicht allein durch die Verwendung einer Umgebung in einem isolierten Container laufen. Ein Workflow kann zum Weg um eine sonst sorgfältige Repository-Richtlinie werden.

Cloud-Konsolen, Hostinganbieter, Datenbanken, Domainregistrare und Beobachtungssysteme haben eigene Zugriffsmodelle. Legen Sie deren Zugänge nicht in einem GitHub-Issue ab und geben Sie einem externen Entwickler kein allgemeines Produktionskonto, nur weil die Repository-Rolle kontrolliert wirkt. Erstellen Sie nach Möglichkeit separate zeitlich begrenzte Identitäten, dokumentieren Sie deren Eigentümer und entziehen Sie sie im selben Abschlussprozess.

Muss das externe Team eine Reparatur in der Produktion ausführen, verlangen Sie eine interne Freigabe und einen schriftlichen Rückweg. Die Person, die die Änderung geschrieben hat, sollte sie erklären. Eine andere Person sollte entscheiden, ob sie auf Live-Daten ausgeführt wird. Kleine Teams können Aufgaben nicht immer perfekt trennen. Sie können trotzdem ein ausdrückliches Freigabeereignis verlangen und den Grund aufbewahren, statt das Deployment als beiläufige Folge eines Merges geschehen zu lassen.

Audit-Nachweise brauchen einen Eigentümer

Ein Audit-Protokoll hilft nur, wenn jemand weiß, welche Ereignisse zu prüfen sind und welche Entscheidung die Aufzeichnung belegen soll. Sammeln Sie Nachweise während des gesamten Auftrags, nicht erst nach einer verdächtigen Änderung oder einem hastigen Entzug.

Das Audit-Protokoll einer GitHub-Organisation erfasst, wer gehandelt hat, welche Aktion stattfand, wann sie geschah und welches Repository betroffen war. Laut Dokumentation können Organisations-Owner darin suchen, und Audit-Ereignisse bleiben für einen begrenzten Zeitraum verfügbar. Benennen Sie deshalb eine interne Person, die die von Ihrer Richtlinie verlangten Nachweise exportiert oder aufbewahrt. Das externe Team darf nicht alleiniger Verwahrer der Aufzeichnungen sein, mit denen sein eigener Zugriff bewertet wird.

Verwenden Sie eine gespeicherte Suche nach Repository, Akteuren und Auftragszeitraum. Zum Beispiel:

repo:acme/example-app actor:vendor-engineer created:2026-08-01..2026-08-15

Die Review-Aufzeichnung sollte Felder wie Aktion, Akteur, Repository, Quelle und Zeitpunkt enthalten. Ein kompaktes normalisiertes Ereignis kann so aussehen:

{"action":"protected_branch.update","actor":"vendor-engineer","repo":"acme/example-app","created_at":"2026-08-04T14:22:10Z"}

Die genauen verfügbaren Ereignisse hängen von der Aktion und Kontokonfiguration ab. Testen Sie die Suche daher vor Arbeitsbeginn. Nehmen Sie eine harmlose, genehmigte Änderung vor, bestätigen Sie das erwartete Ereignis und prüfen Sie, ob die verantwortliche Person darauf zugreifen kann. Erst nach dem Auftrag festzustellen, dass niemand das Organisationsprotokoll sehen konnte, ist keine Audit-Strategie.

Prüfen Sie Quellcodeänderungen außerdem über Git. Pull Requests sollten einen Befund mit der Reparatur verbinden, das betroffene Verhalten nennen, Tests ausweisen und Review-Kommentare bewahren. Releases oder Deployments sollten auf den gemergten Commit zeigen. Änderungen an Repository-Einstellungen brauchen eine eigene Genehmigungsaufzeichnung, weil sie möglicherweise nicht in einem Code-Diff auftauchen.

Prüfen Sie Zugriffsereignisse zu drei Zeitpunkten: nach Einladungen und Rollenzuweisungen, nach jeder vorübergehenden Erhöhung und beim Entzug. Suchen Sie nach zusätzlichen Mitwirkenden, Rollenänderungen, Deployment-Schlüsseln, neuen Apps, Webhooks, Umgehungsakteuren, Umgebungsänderungen, Workflow-Anpassungen und unerwarteten persönlichen Zugriffswegen. GitHub warnt, dass das Entfernen eines Nutzers einen anderswo vorhandenen Deployment-Schlüssel nicht unwirksam macht. Schließen Sie Schlüssel und installierte Automatisierung deshalb in die Abschlussprüfung ein.

Überfluten Sie die verantwortliche Person nicht mit Rohereignissen. Das endgültige Nachweispaket sollte vier Fragen beantworten: Wer hatte Zugriff, was wurde geändert, wer genehmigte sensible Änderungen und wurde jeder Zugriffsweg entfernt oder übertragen? Bewahren Sie Rohexporte entsprechend Ihrer Richtlinie auf, schreiben Sie aber zusätzlich eine kurze Ausnahmeliste, die eine spätere Wartungsperson versteht.

Der Entzug beginnt vor dem ersten Commit

Legen Sie das Entzugsdatum bei der Vergabe des Zugriffs fest, benennen Sie die ausführende Person und definieren Sie den Abschluss. Ein in einem Vertrag verstecktes Enddatum entfernt weder Mitwirkende noch Token, Deployment-Schlüssel, Cloud-Konten oder kopierte Secrets.

Verwenden Sie einen Kalendereintrag oder ein Ticket, das vor dem geplanten Ende geöffnet wird. Die interne verantwortliche Person braucht genug Zeit, um offene Branches zu prüfen, Issues zu übertragen, die Deployment-Verantwortung zu bestätigen und über eine enge Verlängerung zu entscheiden. Verlängerungen müssen ausdrücklich vereinbart und datiert sein. „Vielleicht helfen sie später noch einmal“ ist kein Grund, den Zugriff auf ein privates Repository zu behalten.

Die Abschlussliste sollte jeden für die Arbeit geschaffenen Zugriffsweg abdecken:

• Entfernen Sie externe Mitwirkende oder die für den Auftrag gewährte Organisationsmitgliedschaft.
• Entziehen Sie Teamzugriffe, temporäre Token, GitHub Apps, Deployment-Schlüssel und nicht mehr benötigte Maschinenzugänge.
• Entfernen Sie das Team aus Umgehungslisten, Code-Eigentümerschaft, verpflichtenden Reviewer-Gruppen und Umgebungsfreigaben.
• Übertragen Sie offene Pull Requests, Issues, Betriebsanleitungen und Release-Verantwortung an namentlich bestimmte interne Eigentümer.
• Ersetzen Sie jedes Secret, das das Team erhalten hat, wenn sein fortbestehender Besitz ein untragbares Risiko schafft.

GitHub erklärt, dass das Entfernen eines Mitwirkenden aus einem privaten Repository den Zugriff beendet und private Forks in den zutreffenden Fällen löscht. Lokale Klone bleiben bestehen. Lassen Sie sich schriftlich bestätigen, dass das Team gespeicherten Quellcode und Daten entsprechend den vereinbarten Löschregeln behandelt hat. Dies ist eine rechtliche und betriebliche Kontrolle, keine GitHub-Funktion.

Prüfen Sie nach dem Entfernen die Repository-Zugriffe in einer frischen Ansicht, statt dem Ticketstatus zu vertrauen. Suchen Sie im Audit-Protokoll nach Entfernungsereignissen, prüfen Sie installierte Apps und Deployment-Schlüssel, bestätigen Sie die Reviewer der Umgebungen und sehen Sie die Basisberechtigungen der Organisation durch. Eine Person, deren direkte Zuweisung zu einem Repository entfernt wurde, kann über einen anderen Weg weiterhin Zugriff erben.

Bewahren Sie die Reparaturhistorie. Löschen Sie Branches oder Gespräche nicht nur deshalb, damit das Repository sauber aussieht, bevor interne Eigentümer die Arbeit angenommen haben. Mergen oder schließen Sie Pull Requests bewusst, bewahren Sie die nach Ihrer Richtlinie nötigen Nachweise und löschen Sie danach überholte Branches über den normalen Repository-Prozess.

Ein Sanierungsteam sollte weniger betriebliche Unklarheit hinterlassen, als es vorgefunden hat. Wenn nach Abschluss niemand die aktuellen Repository-Administratoren, Produktionsfreigebenden, aktiven Zugänge und das nächste Entzugsdatum nennen kann, ist der Code vielleicht besser, doch das Eigentumsproblem besteht fort. Schließen Sie beides ab.