CodeRabbit startet Deep Scan, um Logikfehler in eingecheckptem Code aufzuspüren

Warum Angreifer laut CodeRabbit im Vorteil sind

CodeRabbit beschreibt ein bekanntes Problem: Ein Dienst läuft über Jahre mit bestandenen Tests, gepatchten Abhängigkeiten und Scans bei jedem Pull Request, während ein Fehler in der eigenen Logik der Anwendung unbemerkt bleibt. Betrachtet man den Code Funktion für Funktion, wirkt er sicher. Die Schwachstelle zeigt sich erst, wenn jemand einen ganzen Workflow nachverfolgt und fragt, welche Annahmen der Code unterwegs trifft.

Laut CodeRabbit kann ein Angreifer diese Arbeit dank KI inzwischen erledigen, ohne die Codebasis zu kennen. Das Unternehmen verweist auf einen Bericht, den Anthropic im November 2025 über eine KI-gesteuerte Spionagekampagne veröffentlicht hat. Dabei habe die KI 80 bis 90 Prozent der taktischen Arbeit übernommen, menschliche Operatoren seien nur an wenigen Entscheidungspunkten eingeschritten. Die Angreifer nahmen rund 30 Organisationen ins Visier und drangen in einige wenige davon ein.

CodeRabbit folgert, dass dieselbe Fähigkeit einem Team helfen kann, das Problem als Erstes zu finden, auch in Diensten, deren ursprüngliche Autoren längst weitergezogen sind. In einem agentischen Softwareentwicklungszyklus könne die Verantwortung für alten Code nicht allein bei der Sicherheitsabteilung liegen, ergänzt das Unternehmen, die Entwicklung trage sie mit.

Wo Deep Scan neben bestehenden Scannern steht

CodeRabbit versteht Deep Scan nicht als Ersatz für vorhandene Werkzeuge. Statische Analyse könne Daten über Funktionen hinweg verfolgen und unsichere Datenflüsse erkennen, Dependency-Tools markierten bekannte verwundbare Pakete, und Secret-Scanner suchten nach offengelegten Zugangsdaten. Diese Werkzeuge solle man behalten, so das Unternehmen.

Deep Scan soll als zusätzliche Schicht logischen Schlussfolgerns dienen, und zwar für Fehler, die womöglich zu keiner bekannten Regel, keinem verwundbaren Paket und keinem offengelegten Secret passen. CodeRabbit räumt ein, dass sich Regeln für bestimmte Autorisierungsmuster schreiben lassen. Schwierig sei jedoch, jede anwendungsspezifische Verpflichtung im Voraus auszudrücken, besonders wenn ein Workflow sie auf mehrere Komponenten verteilt. Die semantische Analyse von Deep Scan ermittelt stattdessen, was die Anwendung durchsetzen soll, und sucht dann in der Implementierung nach Belegen, die diese Hypothese stützen oder widerlegen. Zudem prüft sie, ob eine Kontrolle tatsächlich fehlt und was ein Angreifer ohne sie tun könnte.

Zur Veranschaulichung spielt CodeRabbit einen vereinfachten Erstattungs-Workflow durch. Ein Handler prüft, dass jede einzelne Erstattungsanfrage den erfassten Zahlungsbetrag nicht übersteigt. Ein Kunde, der 100 US-Dollar bezahlt hat, kann zweimal eine Erstattung von 60 US-Dollar beantragen, und beide Anfragen bestehen die Prüfung, obwohl sie zusammen die Zahlung übersteigen. Ob tatsächlich eine überhöhte Erstattung vorliegt, hängt von Fragen ab: Liest der Worker die Erstattungshistorie? Werden Mittel reserviert, bevor der Zahlungsanbieter kontaktiert wird? Erzwingt der Anbieter ein kumulatives Limit? Lehnt der Anbieter Erstattungen über dem verbleibenden Guthaben ab, würde das Beispiel laut CodeRabbit keine erfolgreiche Überzahlung belegen, und sie zu melden hieße, einen Schutz auf dem Ausführungspfad zu ignorieren.

So funktioniert ein Deep Scan

Deep Scan liest die eingecheckte Codebasis und nicht nur die in einem Pull Request geänderten Zeilen. Eine verdächtige Operation sage wenig aus ohne den Code, der bestimmt, wer sie erreichen kann und welche Schutzmaßnahmen greifen, so CodeRabbit.

• Erst der Kontext: Der Scan untersucht sicherheitsrelevante Teile des Repositorys, darunter Einstiegspunkte, Vertrauensgrenzen, Zugriffskontrollen, sensible Operationen und Sicherheitskonfiguration. Verknüpfte Repositories können schreibgeschützten Kontext liefern, und ein Fund, der sich auf eine verknüpfte Quelle stützt, zeigt Repository, Datei, Commit und Quelllink.
• Hypothese gegen Code: Der Scan folgt relevanten Pfaden und sammelt den Code hinter einem möglichen Fund. Funktionsnamen, Kommentare und Architekturbeschreibungen können die Untersuchung orientieren, beweisen aber nicht, dass eine Schutzmaßnahme tatsächlich ausgeführt wird.
• Unabhängige Gegenprüfung: Laut CodeRabbit ist die Sicherheitsprüfung unabhängig von dem Agenten, der den Code geschrieben hat. Ein separater Verifier prüft Erreichbarkeit, bestehende Schutzmaßnahmen und die Bedingungen für eine Ausnutzung und verwirft Kandidaten, die Schutzmechanismen übersehen oder auf unbelegten Annahmen beruhen.

Jeder veröffentlichte Fund trägt eine Bewertung für Erreichbarkeit und Ausnutzbarkeit. Die Liste ist damit danach geordnet, was ein Angreifer tatsächlich erreichen könnte, und nicht danach, was ein Muster getroffen hat.

Was das für Entwicklungsteams bedeutet

CodeRabbit spricht offen über die Grenzen des Ansatzes. Ein zweites Modell sei weiterhin ein Modell und könne dieselbe falsche Annahme wiederholen wie das erste. Deshalb bleiben die Belege für den Entwickler sichtbar, der Wissen über die Bereitstellung, geschäftliche Einschränkungen und das Verhalten externer Dienste einbringen kann, über das der Scan womöglich nicht verfügt.

Für Teams lautet das Versprechen, dass Funde als nachvollziehbare Pfade vom Einstiegspunkt bis zur sensiblen Operation geliefert werden. Entwickler können so die fehlende Schutzmaßnahme verstehen und die Schlussfolgerung hinterfragen, bevor sie entscheiden, was sie ändern. Angaben zu Preisen oder Verfügbarkeit macht die Quelle nicht.