GitLab Duo Security Review erkennt Logikfehler, die Scanner übersehen

Statische Scanner sind stark darin, Schwachstellen zu erkennen, die einem bekannten Muster folgen, etwa ungeprüfte Query-Inputs, hartcodierte Secrets oder unsichere Deserialisierung. Schwierig wird es bei Fehlern in der Anwendungslogik, wo kein Muster zum Abgleich existiert – nur validen Code, der für die jeweilige Domäne das Falsche tut. Bleiben solche Fehler unentdeckt, treten sie erst spät zutage und werden teurer in der Behebung.

Security Review Flow, jetzt in der Public Beta, prüft Code-Änderungen so, wie es ein Security Engineer tun würde. Anstatt Signaturen abzugleichen, verfolgt der Flow die Absicht hinter dem Code, um Logikfehler vor der Produktion zu erkennen. Das ist ein wichtiger Schritt, um gefährliche Fehler aufzudecken, die Scanner meist übersehen.

Wo musterbasierte Scanner blind bleiben

Die schädlichsten Schwachstellen wirken Zeile für Zeile oft korrekt, verletzen aber einen Kontext, der im Code selbst nicht enthalten ist – etwa das Autorisierungsmodell, Regeln zur Sensibilität von Daten oder die vorgesehenen Workflows. Drei der häufigsten Schwachstellenklassen im Überblick:

Zugriff und Autorisierung: Ob Nutzende eine Ressource lesen oder ändern dürfen, legt das Autorisierungsmodell fest, nicht ein Sprachkonstrukt. Broken Object Level Authorization (der Zugriff auf die Daten anderer Nutzender durch das Ändern einer ID) führt die OWASP API Security Top 10 seit 2019 an.

Data Exposure: Ein Objekt zu serialisieren und zurückzugeben, ist gewöhnlicher, korrekt wirkender Code. Ob dabei Daten offengelegt werden, hängt davon ab, welche Felder sensibel sind und wer sie erhält – Fakten der jeweiligen Domäne, nicht der Syntax.

Kontrollfluss und Workflow: Business-Logic- und Race-Condition-Fehler entstehen, wenn valide Operationen in falscher Reihenfolge ablaufen, unerwartet wiederholt werden oder manipuliert werden. Beispiele sind ein Checkout, der ohne Zahlung erreichbar ist, ein Status, der durch eine Race Condition erneut betreten wird, oder ein Parameter, der zur Preisänderung manipuliert wird.

Solche Fehler zu erkennen, erforderte bisher entweder manuelles Security Review, das sich über jede Merge Request (MR) hinweg nur teuer skalieren lässt, oder Penetration Testing und Bug Bounties, die zu spät greifen. Die Folge ist eine wachsende Lücke zwischen dem Tempo der Entwicklung und dem Umfang, in dem Security-Expertise angewendet werden kann.

Security-Expertise in jede MR einbringen

Security Review Flow, ein Foundational Flow auf der GitLab Duo Agent Platform, schließt diese Lücke, indem er nachvollzieht, was der Code eigentlich leisten soll. Er erkennt genau die oben beschriebenen Fehlerklassen: Broken Object Level Authorization und Broken Function Level Authorization, fehlende Autorisierung bei zustandsändernden Operationen, Information Disclosure, Mass Assignment, Business-Logic-Fehler und Race Conditions in zustandsbehafteten Workflows.

Er ergänzt klassische Scanner und menschliche Analyse, statt sie zu ersetzen, und prüft Code genau zum Zeitpunkt der Änderung, wenn eine Korrektur am günstigsten ist. GitLabs eigenes Application-Security-Team hat Security Review Flow während der gesamten Entwicklung über interne MRs hinweg eingesetzt.

Security Review Flow in Aktion:

So funktioniert es

Ist eine MR bereit, lässt sich ein Review von Duo Security Review anfordern – genau wie von einer Person. Der Flow analysiert den Diff im Kontext: die Originaldateien, geänderte Zeilen, die MR-Diskussion und verwandten Code. Seine Reasoning-Logik ist auf Präzision optimiert, und ein unabhängiger Validierungsschritt prüft jeden Finding, um wahrscheinliche False Positives herauszufiltern.

Findings erscheinen als Diff-Threads an den relevanten Zeilen, ergänzt durch eine Zusammenfassung in einer internen Notiz. Bei öffentlichen Projekten bleiben sie auf die interne Notiz beschränkt, sodass keine Security-Details offengelegt werden.

Jedes Finding liefert den Kontext, der für das Review nötig ist:

• Vulnerability Type mit CWE-Referenz
• Severity: Critical, High, Medium oder Low
• Tier: Tier 1 (Exploitable), Tier 2 (Logic Flaw) oder Tier 3 (Design Issue)
• Eine verständliche Erklärung des Problems
• Ein Fix-Vorschlag, sofern verfügbar

Die Severity bestimmt den Review-Status: Ein Critical- oder High-Finding setzt ihn auf Request changes, während Medium- oder Low-Findings zu Comment führen. Der Flow genehmigt nie – auch dann nicht, wenn er nichts findet –, die finale Entscheidung liegt immer bei einem Menschen.

Von dort aus lässt sich der Duo-Security-Review-Service-Account der jeweiligen Organisation in einem Kommentar-Thread erwähnen, um eine Frage zu stellen, die Behebung zu diskutieren oder ein Finding infrage zu stellen. Jedes Finding lässt sich auflösen, indem der Fix als Standard-MR-Suggestion übernommen, als False Positive verworfen oder das Risiko akzeptiert wird. Nach dem Commit der Fixes lässt sich ein neues Review anfordern, um die Änderungen zu prüfen.

Den ersten Security Review Flow ausführen

Security Review Flow befindet sich für die GitLab-Ultimate-Kundschaft in der Public Beta. Verfügbar ist der Flow auf GitLab.com, GitLab Self-Managed und GitLab Dedicated.

Der Einstieg gelingt über die Security-Review-Flow-Dokumentation.

Der Zugang zu Security Review Flow lässt sich über eine kostenlose Testversion der GitLab Duo Agent Platform erhalten. Bereits im GitLab-Ultimate-Abo? Die Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.

Die Kosten variieren je nach Komplexität des Diffs und dem gewählten Modell – ein Test an wenigen MRs empfiehlt sich, bevor der Flow breiter eingesetzt wird. Die Preisgestaltung kann zur allgemeinen Verfügbarkeit angepasst werden.

Feedback lässt sich im Feature-Feedback-Issue teilen – so fließt es direkt in die Weiterentwicklung ein.