Dein Blog zum Thema digitales Business

Jede Softwareorganisation hat einen Freigabeprozess. Irgendjemand entscheidet, dass ein Stand in Produktion geht. Die Frage im Audit lautet aber nicht, ob es diesen Prozess gibt. Sie lautet: Kannst du für ein beliebiges Release vom letzten Jahr zeigen, wer freigegeben hat, auf welcher Grundlage und ob die Regel technisch erzwungen war? Genau daran scheitern viele Teams, obwohl sie fachlich sauber arbeiten.

Warum „wir machen Vier-Augen-Prinzip“ nicht reicht

Ein Prüfer akzeptiert keine mündliche Beschreibung. Er will drei Dinge sehen: eine definierte Regel, den Nachweis, dass die Regel technisch erzwungen wird, und die Belege für konkrete Fälle. Wenn die Freigabe in der Praxis darin besteht, dass der Teamlead im Chat „passt, deploy“ schreibt, existiert der Prozess zwar, aber er ist weder erzwungen noch belegbar. Chat-Nachrichten sind kein Audit-Trail. Sie sind durchsuchbar, löschbar und an keine technische Kontrolle gebunden.

Die drei Bausteine

Erstens die Regel. Sie muss irgendwo stehen, versioniert und datiert. Ein kurzes Markdown-Dokument im Repo reicht: Wer darf freigeben, was wird geprüft, welche Ausnahmen gibt es. Zweitens die Erzwingung. Die Regel muss im Werkzeug hinterlegt sein, so dass ein Verstoß technisch nicht möglich ist oder zumindest sichtbar wird. Drittens der Nachweis. Das System muss festhalten, wer wann was freigegeben hat, und diese Daten müssen exportierbar sein.

Wie das in GitHub konkret aussieht

Die Erzwingung liegt in Branch Protection beziehungsweise Rulesets auf dem Produktiv-Branch: Pull Request Pflicht, mindestens ein Review, keine Self-Approval nach eigenem Push, Status Checks müssen grün sein. Wer die Reviews macht, steuert CODEOWNERS. Für den Schritt in die Produktionsumgebung kommen Environments mit Required Reviewers dazu: Das Deployment startet erst, wenn eine benannte Person oder Gruppe im Workflow bestätigt hat. Damit ist die Freigabe an den konkreten Deploy gebunden, nicht nur an den Merge. In GitLab leisten Protected Branches, Approval Rules und Protected Environments dasselbe.

Der Nachweis: wo die Daten liegen

Die gute Nachricht: Die Belege entstehen automatisch. Jeder Pull Request speichert Reviewer, Zeitstempel und Diskussion. Jede Environment-Freigabe landet im Deployment-Verlauf. Das Audit-Log der Organisation hält fest, wer Schutzregeln geändert hat. Die schlechte Nachricht: Diese Daten liegen verstreut und niemand hat sie je zu einem Bericht zusammengeführt. Wenn der Prüfer fragt, heißt es dann: Das müssten wir raussuchen. Ein einfaches Skript, das pro Release die zugehörigen Pull Requests, Reviews und Deployment-Freigaben als Tabelle exportiert, verwandelt verstreute Metadaten in einen belastbaren Trail. Das ist ein Nachmittag Arbeit und spart im Audit Tage.

Die typischen Lücken

In der Praxis sehen wir drei Muster. Erstens: Branch Protection existiert, aber Admins dürfen sie umgehen, und das Bypass-Recht wird auch genutzt. Damit ist die Erzwingung für den Prüfer wertlos, wenn die Umgehungen nicht begründet und dokumentiert sind. Zweitens: Der Review ist Pflicht, aber jeder darf reviewen, auch wer fachlich nichts mit dem Code zu tun hat. Ohne CODEOWNERS ist das Vier-Augen-Prinzip formal erfüllt und inhaltlich leer. Drittens: Hotfixes laufen an allem vorbei, weil es schnell gehen muss. Ein Audit-fähiger Prozess braucht einen definierten Notfallpfad mit nachträglicher Prüfung, sonst reißt jeder Vorfall ein Loch in den Trail.

Wo stehst du?

Wenn du nicht sicher bist, ob dein Freigabeprozess einer Prüfung standhält, schafft der GitSecOps QuickCheck Klarheit: Wir prüfen deine Pipeline und deine Repo-Konfiguration auf Erzwingung, Nachweisbarkeit und die typischen Lücken. Ergebnis in 3 Werktagen, 1.990 Euro netto. Kontakt: mm@crank.zone.