Dein Blog zum Thema digitales Business

Eine Branch Protection Rule fühlt sich an wie ein Schloss: einmal eingerichtet, sichert sie den Branch dauerhaft ab. Tatsächlich ist sie eher ein Regelwerk mit eingebauten Ausnahmen, und die Frage ist nicht, ob es Ausnahmen gibt, sondern wer sie kennt. Der Beitrag vom 6. August (Vier-Augen-Prinzip in der Pipeline) hat gezeigt, wie sich ein Reviewer umgehen lässt, obwohl die Regel korrekt konfiguriert ist. Hier geht es um etwas Vorgelagertes: die Lücken, die in der Konfiguration der Regel selbst stecken, unabhängig davon, wie sorgfältig ein Reviewer arbeitet.

Wer die Regel umgehen darf, ohne sie zu brechen

In der klassischen Branch Protection entscheidet eine einzelne Einstellung darüber, ob Administratoren an die Regel gebunden sind: „Do not allow bypassing the above settings“. Bleibt sie deaktiviert, dürfen Repository- und Organisationsadmins Required Reviews, Required Status Checks und Force-Push-Sperren umgehen, ohne dass das im Pull Request wie eine reguläre Merge-Aktion sichtbar wird. Rulesets lösen das granularer über eine explizite Bypass List pro Rolle, Team oder App, aber granularer heißt nicht automatisch sicherer: Eine Bypass List, die niemand regelmäßig gegen den tatsächlichen Bedarf prüft, wächst über Jahre und deckt am Ende mehr Rollen ab, als ursprünglich vorgesehen war. Die Regel selbst meldet diesen Zustand nirgendwo, sie liegt einfach in der Konfiguration, bis jemand gezielt nachsieht.

Force-Push: die Ausnahme für einzelne Akteure

Force-Push-Sperren lassen sich für bestimmte Nutzer, Teams oder Apps gezielt aufheben, etwa weil ein Bot oder ein Deploy-Prozess regelmäßig einen Branch neu schreiben muss. Diese Ausnahme betrifft nicht nur den einen Anwendungsfall, für den sie gedacht war: Jeder Commit, der bereits reviewt und gemergt wurde, lässt sich über denselben Kanal überschreiben, inklusive Historie und Signaturen. Wenn ein Token oder ein Deploy-Key breiter berechtigt ist als der eine Workflow, für den er eingerichtet wurde, reicht die Ausnahme weiter als geplant. Die Regel „kein Force-Push“ steht dann zwar in der Konfiguration, aber sie gilt schon nicht mehr für alle.

Ein Status-Check ist ein Name, keine Pipeline

Required Status Checks prüfen nicht, ob eine bestimmte Pipeline gelaufen ist, sondern ob für den aktuellen Commit ein Eintrag mit exakt diesem Namen und dem Status „erfolgreich“ existiert. Diese Unterscheidung wird genau dann zur Lücke, wenn ein Team einen neuen Check als „required“ einträgt: Der Name muss vorher nirgendwo reserviert werden, und alles, was mit ausreichenden Schreibrechten am Repository einen Statuseintrag mit diesem Namen setzen kann, egal ob über die eigentliche Pipeline oder über einen anderen Workflow mit denselben Berechtigungen, erfüllt die Anforderung formal. Wird ein Job umbenannt, ohne die Liste der Required Checks anzupassen, bleibt der alte Name als Anforderung stehen, produziert aber nichts mehr, und ein Merge hängt fest, bis jemand das bemerkt und korrigiert oder ihn per Bypass umgeht. Beides sind keine Fehler in GitHub selbst, sondern Lücken, die entstehen, wenn eine Regel eingerichtet und danach nicht mehr angefasst wird.

Warum das eine andere Baustelle ist als der Reviewer

Der Vier-Augen-Beitrag vom 6. August beschreibt, wie Menschen eine korrekt konfigurierte Regel im Alltag umgehen: veraltete Approvals, Selbstfreigabe über einen zweiten Account, ein schneller Direkt-Push, wenn die Zeit drängt. Die drei Punkte hier liegen davor, in der Konfiguration selbst. Eine Regel, die technisch lückenlos durchgesetzt wird, kann trotzdem umgangen werden, wenn ein Reviewer nachlässig ist. Umgekehrt hilft der sorgfältigste Reviewer nichts, wenn die Regel selbst Administratoren ausnimmt oder ein Status-Check nur dem Namen nach existiert. Wer beides prüfen will, braucht zwei getrennte Fragen: Hält sich jeder Mensch an die Regel, und ist die Regel überhaupt so konfiguriert, dass sie das erzwingt, was sie zu erzwingen scheint.

Wer stattdessen die Freigabe-Ebene der Pipeline selbst absichern will, findet dazu einen Beitrag zu GitHub Actions Environments und Approval Gates.

Von der Konfiguration einzelner Repository-Regeln bis zur Frage, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, bis zur Übergabefrage, wem ein System nach dem Go-Live eigentlich gehört: das sind drei unterschiedliche Baustellen, keine einzelne Checkbox. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de.