Dein Blog zum Thema digitales Business

Ein Fork wirkt harmlos. Jemand kopiert ein Repository, um in Ruhe etwas auszuprobieren, ohne den Hauptzweig zu stören. In der Praxis entsteht damit oft eine zweite Kopie des Codes, die niemand mehr im Blick hat und die Zugriffe mitbringt, die im Original längst geregelt waren. Wer Rechte in GitHub sauber führen will, muss verstehen, was ein Fork und ein privates Repo tatsächlich weitergeben.

Was ein Fork wirklich kopiert

Ein Fork kopiert die gesamte Historie, nicht nur den aktuellen Stand. Alles, was jemals committet wurde, ist in der Kopie enthalten. Das schließt versehentlich eingecheckte Tokens, Konfigurationsdateien mit internen Hostnamen und alte Zugangsdaten ein. Selbst wenn diese Werte im Original später entfernt wurden, bleiben sie in der Historie des Forks liegen. Ein rotierter Schlüssel hilft nur, wenn er überall rotiert wird, auch dort, wo die Kopie inzwischen liegt.

Dazu kommt die Sichtbarkeit. Ein Fork eines privaten Repos bleibt zunächst privat, aber die Person, die geforkt hat, ist jetzt Eigentümerin ihrer eigenen Kopie. Sie entscheidet, wer darauf Zugriff bekommt, und sie kann die Kopie behalten, auch wenn sie später aus dem ursprünglichen Team entfernt wird.

Die stille Vererbung in Organisationen

In einer GitHub-Organisation hängen Rechte selten am einzelnen Repo. Sie kommen über Team-Mitgliedschaften, über Organisationsrollen und über Standardberechtigungen, die für alle neuen Repos gelten. Genau diese Vererbung macht es schwer zu erkennen, wer auf einen Fork oder ein privates Repo tatsächlich zugreifen kann. Der nominale Zugriff im Repo-Dialog und der effektive Zugriff über Teamketten sind oft nicht dasselbe. Wir haben das im Beitrag zu effektiven gegen nominale Rechte ausführlich beschrieben.

Bei Forks innerhalb der Organisation greift diese Vererbung ebenfalls. Wer ein internes Repo forkt, nimmt je nach Konfiguration die Standardrechte der Organisation mit in die neue Kopie. So entstehen Repos, auf die mehr Personen Zugriff haben, als der Ersteller je beabsichtigt hat.

Wo es konkret schiefgeht

Drei Muster tauchen immer wieder auf. Erstens der verwaiste Fork: Jemand forkt für ein kurzes Experiment, verlässt Monate später das Team, und die Kopie bleibt mit ihrer kompletten Historie bestehen. Beim Offboarding wird das Original geprüft, der Fork im persönlichen Namensraum aber übersehen.

Zweitens das private Repo mit zu breitem Team. Ein Repo wird als privat angelegt und fühlt sich dadurch geschützt an. Der Zugriff läuft aber über ein großes Team, das mit der Zeit gewachsen ist. Privat heißt hier nicht klein, sondern nur nicht öffentlich.

Drittens der Fork, der zurück nach außen wandert. Ein internes Repo wird geforkt, die Kopie später versehentlich auf öffentlich gestellt. Damit ist die gesamte Historie inklusive alter Geheimnisse für jeden lesbar.

Was hilft

• Fork-Richtlinien in der Organisation festlegen. GitHub erlaubt, das Forken interner und privater Repos einzuschränken oder ganz zu unterbinden.
• Regelmäßig prüfen, welche Forks von internen Repos existieren und wem sie gehören. Verwaiste Kopien werden entfernt, nicht geduldet.
• Geheimnisse nie über das Entfernen aus dem aktuellen Stand als erledigt betrachten. Rotieren, weil die Historie in jeder Kopie weiterlebt.
• Zugriffe auf private Repos regelmäßig gegen die tatsächlichen Teamketten prüfen, nicht gegen die Absicht. Ein wiederkehrender Berechtigungs-Review macht das sichtbar.

Der gemeinsame Nenner: Eine Kopie ist kein Nebenschauplatz. Sie ist ein vollwertiges Repo mit eigener Historie und eigenen Rechten, das genauso in die Rechteführung gehört wie das Original.

Wollen Sie wissen, welche Forks und Zugriffe in Ihrer GitHub-Organisation tatsächlich offen sind? Der GitSecOps QuickCheck prüft Ihre Pipeline und Repo-Rechte auf genau solche blinden Flecken. Festpreis 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.