Die meisten Sicherheitsdiskussionen drehen sich um Tools: Scanner, Secrets-Vaults, Signaturen. Eine der wirksamsten Kontrollen kostet nichts und ist in jedem GitHub-Repository schon eingebaut. Branch Protection. Sie entscheidet, wer Code in den Hauptzweig bringt und unter welchen Bedingungen. Trotzdem läuft sie in vielen Teams ungenutzt oder halb konfiguriert mit.
Was Branch Protection eigentlich macht
Branch Protection ist eine Regel, die direkten Zugriff auf einen Branch einschränkt. Ohne sie kann jeder mit Schreibrechten direkt auf main pushen, die Historie umschreiben oder den Zweig löschen. Mit aktiver Protection führt der Weg in den Hauptzweig nur über einen Pull Request, der definierte Bedingungen erfüllt. Das klingt nach Bürokratie, ist aber die Stelle, an der ein Repository von „jeder kann alles“ zu „Änderungen sind nachvollziehbar“ wechselt.
Der Punkt ist nicht, Entwickler auszubremsen. Der Punkt ist, dass jede Änderung am produktiven Stand einen Pfad nimmt, den man später nachvollziehen kann. Wer hat was wann freigegeben, welche Checks liefen, wer hat reviewt. Diese Spur entsteht automatisch, sobald die Regel greift.
Die Regeln, die wirklich zählen
GitHub bietet ein gutes Dutzend Optionen. Vier davon tragen den Großteil des Nutzens.
- Pull Request vor dem Merge erforderlich. Kein direkter Push auf den geschützten Branch. Jede Änderung läuft über einen PR.
- Mindestens ein Review. Eine zweite Person muss zustimmen. Bei kleinen Teams oft die wichtigste Hürde gegen Flüchtigkeitsfehler und untergeschobenen Code.
- Status-Checks müssen grün sein. Tests, Linter, Security-Scans laufen, bevor gemergt werden kann. Ein roter Build blockiert den Merge.
- Branch muss aktuell sein. Der PR wird gegen den neuesten Stand getestet, nicht gegen einen veralteten. Das verhindert, dass zwei einzeln grüne Änderungen zusammen den Build brechen.
Ergänzend sinnvoll: Force-Pushes verbieten und das Löschen des Branches sperren. Beides schützt die Historie, die im Ernstfall die einzige verlässliche Quelle ist.
Wo die meisten Teams scheitern
Die häufigste Lücke ist nicht das Fehlen der Regel, sondern ihre Aushöhlung. Drei Muster tauchen immer wieder auf.
Erstens: Administratoren sind ausgenommen. Die Option „include administrators“ bleibt aus, und damit umgeht genau die Gruppe die Regel, die am meisten Schaden anrichten kann. Eine Kontrolle, die für die Mächtigsten nicht gilt, ist keine Kontrolle.
Zweitens: Review als Formalität. Wenn die Regel ein Review verlangt, aber jeder alles durchwinkt, entsteht nur Theater. Ein „Approve“ ohne gelesenen Diff ist wertlos und gefährlich, weil es Sicherheit vortäuscht.
Drittens: keine Code Owner. Ohne CODEOWNERS-Datei kann irgendwer irgendwas freigeben, auch in Bereichen, von denen er nichts versteht. Wer sicherheitskritische Pfade definiert und dafür feste Reviewer festlegt, schließt diese Lücke.
Branch Protection ist kein Ersatz für Review-Kultur
Die Regel erzwingt einen Prozess, sie ersetzt kein Urteilsvermögen. Ein Team, das gründlich reviewt, braucht die Regel nur als Absicherung gegen Ausnahmen. Ein Team, das oberflächlich reviewt, gewinnt durch die Regel wenig. Technik und Kultur müssen zusammenkommen. Branch Protection sorgt dafür, dass die Kultur nicht von einem einzigen unter Zeitdruck gesetzten Push ausgehebelt wird.
Erste Schritte
Beginnen Sie mit dem Hauptzweig des wichtigsten Repositories. PR-Pflicht, ein Review, grüne Status-Checks, keine Force-Pushes, Administratoren eingeschlossen. Beobachten Sie eine Woche, wo es klemmt, und justieren Sie. Danach rollen Sie das Muster auf weitere Repositories aus. Der Aufwand liegt im Minutenbereich pro Repo, der Effekt hält dauerhaft.
Wenn Sie wissen wollen, wie gut Ihre Branch-Protection-Regeln über alle Repositories hinweg wirklich greifen und wo Pull-Request- und Pipeline-Kontrollen ausgehebelt werden, liefert der GitSecOps QuickCheck in drei Werktagen einen klaren Befund. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 
Hinterlasse einen Kommentar