GitLab öffnet Early Access für Agenten, der Fehler in der Geschäftslogik aufspürt

Warum Mustererkennung Autorisierungslücken übersieht

GitLab geht von einem Punkt aus, den auch OWASP macht: Broken Object Level Authorization steht auf Platz eins der OWASP API Security Top 10, und herkömmliche Werkzeuge für Static Application Security Testing (SAST) tun sich schwer damit, Fehler in der Zugriffskontrolle zu finden. GitLab erklärt das so: Eine fehlende Autorisierungsprüfung ist die Abwesenheit von Code, ein Scanner, der Muster abgleicht, hat also nichts, was er abgleichen könnte.

Das Unternehmen nennt drei Beispiele, die den meisten Application-Security-Teams vertraut sein dürften. Ein Endpunkt liefert eine Bestellung anhand der ID zurück, ohne zu prüfen, wem sie gehört. Ein Rollenfeld im Nutzerprofil akzeptiert beliebiges JSON, das der Client sendet. Eine Nutzer-ID ist eine fortlaufende Ganzzahl. Jedes dieser Beispiele ist gültiger Code, der an den meisten Taint- und Musterregeln vorbeiläuft, weil keine nicht vertrauenswürdigen Daten an eine gefährliche Senke gelangen und keine bekannte Schadsignatur auftaucht. Verkettet, so GitLab, verschaffen sie einem Angreifer die Bestellungen aller Kunden und eine Administratorrolle.

GitLab verweist zudem auf wachsenden Druck. Bei den Kunden des Unternehmens ist der Umfang der Codebasen um bis zu 500 % gewachsen, weil Agenten Code schreiben, und die CVE-Veröffentlichungen lagen bis April um 46 % über der Februar-Prognose des Forum of Incident Response and Security Teams. Omer Azaria, Vice President of Product Management bei GitLab, sagte auf der GitLab Transcend: „Wir sitzen zwischen den Stühlen: mehr Code, schnellere Angriffe, dieselben Teams.“

So funktioniert der Analyzer

Der Business Logic Security Analyzer ist ein Foundational Flow der GitLab Duo Agent Platform. Er zielt auf Fehler in der Geschäftslogik, beginnend mit Broken Object Level Authorization, fehlender oder unzureichender Autorisierung und Mass Assignment. Anwender können einen Scan des gesamten Repositorys starten, und jeder Merge Request kann nach erfolgreicher Pipeline automatisch gescannt werden.

GitLab zufolge wird das gesamte Repository gescannt, weil viele solcher Fehler in einem Diff nicht sichtbar sind. Ob ein Endpunkt die Eigentümerschaft prüfen sollte, hängt vom Datenmodell ab, von den Rollen, die die Anwendung definiert, und davon, wie andere Endpunkte dieselben Datensätze behandeln. GitLab Duo Security Review sucht bereits in Merge Requests nach Autorisierungsfehlern.

Der Analyzer erfasst zunächst die Einstiegspunkte der Anwendung und bildet ab, wer was tun darf, etwa welche Datensätze zu welchem Nutzer gehören und welche Aktionen administrativ sind. Anschließend liest er jeden Handler im Prüfumfang und kontrolliert, ob die Regel durchgesetzt wird, bevor auf den Datensatz zugegriffen wird.

Die Ergebnisse erscheinen im Vulnerability Report und im Sicherheits-Widget des Merge Requests als vollwertige SAST-Ergebnisse. In der GitLab-Demoanwendung übernimmt die Funktion refund_order eine order_id aus der Anfrage und setzt refunded=1, ohne Eigentümerschaft oder Administratorstatus zu prüfen. Taint-Regeln bleiben still, weil die Abfrage parametrisiert ist. Der Analyzer meldet den Fund als CWE-639, Critical, in app/orders.py:17 und erläutert, dass die Eigentumsprüfung fehlt.

Modelle und der GitLab Security Standard

Laut GitLab ist der Analyzer die erste GitLab-Funktion, die Claude Mythos 5.1 von Anthropic unterstützt, das im Early Access für Kunden in freigegebenen Umgebungen verfügbar ist. Hinzu kommt die Unterstützung für Claude Opus 5.5, Sonnet 5.5, Sonnet 5 und Sonnet 4.6, weitere Modelle sind geplant. Alle laufen als von GitLab verwaltete Modelle über GitLabs AI Gateway, zu denselben Datenschutzbedingungen wie der Rest der GitLab Duo Agent Platform. Nach Angaben von GitLab sieht das Modell nur die Prompts von GitLab und das Repository des Kunden.

Das Werkzeug knüpft an den auf der Transcend vorgestellten GitLab Security Standard an: fünf Stufen, die jeder Agent durchlaufen muss, um mehr Autonomie zu erhalten. Die Stufe Verify verlangt, dass jede Änderung, ob von einem Menschen oder einem Agenten geschrieben, Kontrollen durchläuft, auf die der Autor keinen Einfluss hat. GitLab sagt, der Analyzer laufe außerhalb der Reichweite des Autors, und seine Ergebnisse blieben im selben Report und in denselben Dashboards erhalten wie der Rest der Codebasis.

Was der Early Access umfasst

Die Teilnehmer lassen den Analyzer auf ihren eigenen Codebasen laufen, um echte Treffer zu finden, die ihren Security-Teams noch nicht bekannt waren. GitLab will nach eigenen Angaben mit jedem Team herausarbeiten, wo der Analyzer richtig liegt, falsch liegt oder schweigt.

Jeder Scan verbraucht GitLab Credits, und die Kosten steigen mit der Größe der Angriffsfläche der Anwendung. Interessierte Kunden sollen sich an ihr Account-Team wenden, Nichtkunden an den GitLab-Vertrieb. Sobald eine Gruppe freigeschaltet ist, lässt sich ein Scan des gesamten Repositorys über GitLab Duo Chat oder per API starten. Wird einem Projekt das Scanprofil Business Logic zugewiesen, werden dessen Merge Requests gescannt. Voraussetzungen und Einrichtung sind in der Produktdokumentation beschrieben.