Dein Blog zum Thema digitales Business

Fast jede Organisation, die etwas auf Reviews hält, aktiviert irgendwann Required Reviewers: ein Pull Request braucht mindestens eine fremde Zustimmung, bevor er in den geschützten Branch darf. Auf dem Papier ist das ein Vier-Augen-Prinzip. In der Praxis greift es oft nicht, weil rund um die Regel Umgehungspfade offen bleiben, die niemand bewusst geplant hat.

Was das Vier-Augen-Prinzip technisch bedeutet

Das Prinzip sagt: keine Änderung geht in die Produktion, ohne dass eine zweite Person sie gesehen und freigegeben hat. In GitHub setzt man das über Branch Protection oder Rulesets um, mit der Option „Require a pull request before merging“ und einer Mindestzahl an Zustimmungen. Der Kern ist nicht die Zahl, sondern die Trennung: der Autor einer Änderung ist nicht dieselbe Person, die sie freigibt. Genau diese Trennung fällt still weg, sobald bestimmte Konfigurationen fehlen.

Die Umgehungspfade, die niemand plant

Der erste Pfad ist die Selbstfreigabe. Wenn ein Nutzer seinen eigenen Pull Request genehmigen darf, ist das Vier-Augen-Prinzip formal erfüllt, faktisch aber ausgehebelt. GitHub hat dafür die Einstellung, dass die Freigabe des Autors nicht zählt, aber sie ist nicht überall gesetzt.

Der zweite Pfad ist die veraltete Freigabe. Ein Reviewer stimmt einem Stand zu, danach schiebt der Autor weitere Commits nach, und die alte Zustimmung bleibt gültig. Die zweite Person hat den finalen Code nie gesehen. Ohne „Dismiss stale approvals when new commits are pushed“ prüft niemand mehr, was am Ende tatsächlich gemergt wird.

Der dritte Pfad ist die Administrator-Ausnahme. Solange die Regel nicht auch für Admins und Organisations-Owner gilt, kann jeder mit erhöhten Rechten den Merge-Button ohne Review drücken. In kleinen Teams sind das oft mehr Personen als gedacht, und der schnelle Merge unter Zeitdruck wird zur Gewohnheit.

Der vierte Pfad ist der direkte Push. Wenn der Branch nicht sauber vor Pushes geschützt ist, umgeht ein Push am Pull Request vorbei die Kontrolle komplett. Das Review-Fenster existiert dann nur für die, die sich freiwillig daran halten.

Wann eine Freigabe wirklich zählt

Damit aus der Einstellung eine wirksame Kontrolle wird, müssen mehrere Punkte zusammenkommen. Die Freigabe des Autors darf nicht mitzählen. Neue Commits müssen alte Zustimmungen verwerfen. Die Regel muss ausnahmslos gelten, auch für Admins. Und der geschützte Branch darf nur über den Pull Request erreichbar sein, nicht per direktem Push.

Für Code, der wirklich kritisch ist, lohnt sich zusätzlich die Bindung an Code Owner. Dann genügt nicht irgendeine zweite Person, sondern jemand mit fachlicher Zuständigkeit für den betroffenen Bereich. So wird aus einem Klick eine inhaltliche Prüfung. Wer mehr zur Freigabe an sich wissen will, findet den Velocity-Aspekt in unserem Beitrag Wie ein Software-Freigabeprozess ohne Bremswirkung aussieht.

Kontrolle auf dem Papier gegen Kontrolle in Kraft

Der Unterschied zwischen einer aktivierten Einstellung und einer wirksamen Kontrolle ist genau die Summe dieser Umgehungspfade. Ein Prüfer, der fragt „habt ihr ein Vier-Augen-Prinzip“, bekommt schnell ein Ja. Die ehrlichere Frage ist, unter welchen Bedingungen es umgangen werden kann und wie oft das zuletzt passiert ist. Wer diese Antwort kennt, weiß, ob die Kontrolle real ist oder nur dokumentiert.

Sie wollen wissen, ob Ihre Reviews wirklich greifen oder nur eingeschaltet sind? Der GitSecOps QuickCheck prüft Ihre Pipeline auf genau solche stillen Umgehungspfade und liefert einen priorisierten Befund. 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.