In den vorherigen neun Sessions haben Patrick Steger und ich eine GitLab DevSecOps-Pipeline gebaut, die SAST, Secret Detection, Software Composition Analysis, Container Scanning und DAST ausführt. Nützlich — aber nur dann, wenn sie Probleme tatsächlich findet, bevor der Code im Default-Branch landet. In Teil 10 schliessen wir diesen Loop: Wir hängen die Pipeline an Merge Requests, sodass jede Änderung gescannt wird, die Deltas gegen den Default-Branch sichtbar sind, und Freigaben erforderlich werden, wenn neue High- oder Critical-Vulnerabilities auftauchen.
Warum Merge Requests das eigentliche Gate sind#
Bisher haben wir in den Demos immer direkt auf den Default-Branch committet. Das geht für die Tool-Demonstration, ist aber nicht, wie man ein echtes Projekt fährt. In echten Projekten gibt es eine Branching-Strategie: Du arbeitest auf einem Feature-Branch und mergest ihn schliesslich zurück in den Default-Branch. Die Frage ist, was an genau diesem Merge-Punkt passiert.
GitLabs Antwort: Der Merge Request ist selbst das Security-Gate. Er führt die komplette Pipeline auf dem Working-Branch aus, vergleicht die Security-Findings dieser Pipeline mit dem Default-Branch und reportet die Deltas — was ist neu, was ist verschwunden. Zusätzlich kannst du Approver für neue Critical- oder High-Vulnerabilities definieren. Ohne deren Freigabe ist der Merge blockiert.
Der Workflow von Anfang bis Ende#
Der Ablauf ist derselbe, den die meisten Teams kennen — nur mit Security-Findings dazwischen:
- Feature-Branch für das Issue oder Feature erstellen.
- Merge Request sofort öffnen — er muss nicht “fertig” sein.
- Änderungen committen. Die Pipeline läuft bei jedem Push und reportet neue Security-Findings im Merge Request.
- Code mit Product Owner und anderen Entwicklern reviewen. Findings mit Entwicklern und Security-Experten diskutieren.
- Ist ein Finding ein False Positive, fragst du eine Approval an, um trotzdem zu mergen.
- Mergen, dann den Branch löschen.
Der Punkt, den MR früh zu öffnen, ist derselbe wie in jedem modernen Team: Diskussion findet während der Entwicklung statt, nicht danach.
Wie ein MR in GitLab tatsächlich aussieht#
In der Demo öffnen wir einen vorbereiteten Merge Request mit zwei Änderungen: eine Java-Klasse, die einen unsicheren MessageDigest mit MD5 einführt, und ein Spring-Boot-Upgrade von 2.7.2 auf 2.7.4. Beides ist absichtlich — eines triggert SAST, das andere zwingt SCA, geänderte Dependencies zu prüfen.
Scrollst du runter zur Sektion Security Scanning, sind die neuen Findings inline aufgelistet. Klick auf das SAST-Finding “Inadequate encryption strength”, und GitLab springt direkt zur Code-Zeile, in der MD5 verwendet wird. Genau so soll ein Delta aussehen — kein 200-seitiger Report, sondern “das ist das, was dieser MR hinzugefügt hat.”
Wenn alles grün und reviewt ist, erledigt der Merge-Button am Ende den Rest. Die Pipeline läuft danach erneut auf dem Default-Branch, weil dieser jetzt neuen Code hat.
Das Verhalten konfigurieren#
Die spannenden Settings liegen unter Settings → Merge Requests. Zwei Bereiche sind für DevSecOps relevant.
Merge Checks. “Pipelines must succeed” aktivieren. Genau das, wonach es klingt: Eine rote Pipeline blockiert den Merge. Wir empfehlen das dringend. Es ist die einzige Verteidigungslinie zwischen “die Tools haben etwas gefunden” und “das Etwas ist in main.”
Merge Request Approvals. Weiter unten definierst du Approval Rules. Bei uns gab es bereits eine Regel für den License Check, mit Patrick und mir als Approvers. Darunter kommen die Security Approvals — der mächtige Teil. Du definierst Regeln rund um neue Vulnerabilities: welche Severity, wer freigeben muss, wie viele Approvals nötig sind. Hat deine Organisation eine Security-Abteilung, gib ihr die Rolle des Security Approvers. Sie sieht dann genau, welches neue Risiko ein Merge Request mitbringt, und kann es akzeptieren, ablehnen oder Rückfragen stellen, bevor es im Default-Branch landet.
Die Konfiguration ist umfangreich — beim ersten Mal fast erschlagend. Die gute Nachricht: Du brauchst nur wenige Regeln, um zu starten. Pipeline muss grün sein, plus Security Approval für neue High- und Critical-Vulnerabilities.
Recap#
Der Merge Request ist der Punkt, an dem die GitLab DevSecOps-Pipeline aufhört, ein passiver Scanner zu sein, und ein Gate wird. Die Pipeline läuft auf dem Feature-Branch, die Security-Findings werden gegen den Default-Branch gediffed und inline angezeigt, und definierte Approver müssen freigeben, wenn ernsthafte neue Vulnerabilities auftauchen. Damit bekommt das Team schnelles Feedback während der Entwicklung, Security-Experten sehen nur die für sie relevanten Änderungen, und nichts Kritisches landet ohne bewusste menschliche Entscheidung in main.
In der nächsten Session geht es um Scheduled Pipelines — sicherstellen, dass auch Code, der bereits in Produktion läuft, weiter geprüft wird, selbst wenn niemand committet.
Key Takeaways#
Der Merge Request ist das Gate, nicht die Pipeline. Eine grüne Pipeline auf dem Default-Branch sagt nur etwas über die Vergangenheit. Das Gate ist die MR-Pipeline gediffed gegen main, mit Approvals auf dem Diff.
Merge Requests früh öffnen. Sie sind ein Diskussionswerkzeug, kein Final-Submit-Formular. Frühe MRs bedeuten frühe Reviews, frühes Security-Feedback und weniger Überraschungen kurz vor dem Merge.
Deltas zeigen, nicht Totals. GitLab zeigt im Merge Request neue gegenüber bestehenden Findings. Reviewer fokussieren sich auf das, was diese Änderung neu eingebracht hat — genau das, worauf sie reagieren können.
“Pipelines must succeed” einschalten. Eine Checkbox in Settings → Merge Requests, und sie ist der Unterschied zwischen “der Scanner ist gelaufen” und “der Scanner hat den Merge blockiert”. Lässt du sie aus, ist alles andere Theater.
Security Approval Rules gezielt einsetzen. Konfiguriere sie nach Severity (starte mit High und Critical) und route sie zu den Personen, die wirklich entscheiden können — typischerweise eine kleine Security-Gruppe, nicht jeder Entwickler.
False Positives brauchen einen dokumentierten Ausweg. Irgendwann ist ein Finding falsch. Der Approval-Flow gibt dir einen sauberen Pfad: diskutieren, vom Approver freigeben lassen, mergen — ohne die Regel für alle anderen abzuschalten.