SAST-ähnliche Security-Reviews mit Claude durchführen

1. Wie klassische SAST-Tools grundsätzlich arbeiten

Statische Analysewerkzeuge wie Semgrep, SonarQube oder Checkmarx arbeiten regelbasiert. Sie parsen Quellcode in einen abstrakten Syntaxbaum oder ein vergleichbares Zwischenformat und gleichen diesen gegen eine Bibliothek bekannter Schwachstellenmuster ab: unsichere Deserialisierung, fehlende Escaping-Funktionen vor einer SQL-Query, hartkodierte Zugangsdaten oder die Verwendung veralteter kryptografischer Funktionen. Trifft ein Muster zu, wird eine Warnung erzeugt, unabhängig davon, ob der betroffene Codepfad überhaupt mit nicht vertrauenswürdigen Eingaben in Berührung kommt.

Dieser regelbasierte Ansatz hat zwei zentrale Stärken: Er ist deterministisch, das heißt derselbe Code erzeugt bei jedem Lauf dieselben Treffer, und er ist schnell genug, um bei jedem Commit in der CI-Pipeline zu laufen. Die Kehrseite ist, dass die Regeln lokal auf Codeebene arbeiten und selten den gesamten Datenfluss durch eine Anwendung nachvollziehen. Eine Regel, die auf eine bestimmte Funktion reagiert, kennt weder die Herkunft der übergebenen Daten noch, ob eine vorgelagerte Validierung den kritischen Fall bereits ausschließt.

2. Was kontextuelles Verständnis in der Praxis bedeutet

Claude analysiert Code nicht als isolierte Zeichenkette, sondern im Kontext des gesamten Repositories, das dem Modell über Claude Code oder ein entsprechend aufbereitetes Kontextfenster zur Verfügung steht. Wird ein Parameter aus einem HTTP-Request an eine Funktion übergeben, kann das Modell dem Aufrufpfad über mehrere Dateien hinweg folgen und feststellen, ob zwischen Eingang und kritischer Verwendung tatsächlich eine wirksame Validierung oder Sanitisierung stattfindet. Genau diese Fähigkeit, mehrere Dateien und Aufrufebenen gedanklich zu verknüpfen, unterscheidet den Ansatz von reinem Pattern-Matching.

Der Vorteil zeigt sich besonders bei Schwachstellen, die sich erst aus dem Zusammenspiel mehrerer, für sich genommen unauffälliger Codeteile ergeben, etwa einer Autorisierungsprüfung, die zwar vorhanden ist, aber an der falschen Stelle im Ablauf sitzt und dadurch wirkungslos bleibt. Ein regelbasierter Scanner erkennt, dass eine Prüfung existiert, und meldet keinen Treffer. Claude kann erkennen, dass die Reihenfolge der Operationen die Prüfung faktisch aushebelt, weil die schützenswerte Aktion bereits vor der Prüfung ausgeführt wird.

3. Warum sich beide Ansätze ergänzen statt konkurrieren

Semgrep und SonarQube bleiben für einen Grundstock an Prüfungen unverzichtbar: Sie sind schnell, reproduzierbar und decken bekannte, klar definierbare Muster zuverlässig ab, etwa die Verwendung von eval() mit Nutzereingaben oder das Fehlen von Prepared Statements bei einer Datenbankabfrage. Diese Klasse von Fehlern lohnt sich nicht, bei jedem Review erneut manuell oder per Prompt zu suchen, wenn ein deterministisches Regelwerk sie in Sekunden zuverlässig findet.

Claude entfaltet den größten Mehrwert dort, wo klassische Scanner strukturell an ihre Grenzen stoßen: bei Geschäftslogikfehlern, fehlerhaften Autorisierungsketten über mehrere Services hinweg oder Schwachstellen, die erst im Zusammenspiel mehrerer Änderungen eines Pull Requests entstehen. In der Praxis bewährt sich eine Reihenfolge, bei der Semgrep als schneller, automatisierter erster Filter läuft und Claude anschließend gezielt die Fälle prüft, die ein regelbasiertes Werkzeug prinzipiell nicht erfassen kann.

4. Prompt-Strategie für ein systematisches Pull-Request-Review

Ein wirksamer Prompt für ein Security-Review sollte nicht pauschal nach Sicherheitslücken fragen, sondern eine konkrete Bedrohungsperspektive vorgeben und den Diff mit dem umgebenden Code verknüpfen lassen. Sinnvoll ist es, Claude explizit anzuweisen, für jede geänderte Funktion den Datenfluss von der Eingabe bis zur sicherheitsrelevanten Verwendung nachzuvollziehen, statt nur den Diff isoliert zu betrachten. Das folgende Beispiel zeigt eine Prompt-Struktur, die sich in der Praxis als Ausgangspunkt bewährt hat.

# Claude Code: systematisches Security-Review eines Pull Requests
claude "Führe ein Security-Review für den aktuellen Diff durch (git diff main).
Gehe pro geänderter Funktion wie folgt vor:
1. Identifiziere alle Eingabequellen (HTTP-Parameter, Datenbank, externe APIs).
2. Verfolge den Datenfluss bis zur sicherheitsrelevanten Verwendung (Query,
   Dateisystem, Shell, Template-Rendering).
3. Prüfe, ob zwischen Eingang und Verwendung eine wirksame Validierung
   oder Sanitisierung liegt.
4. Bewerte Autorisierung: greift die Änderung auf Daten oder Aktionen zu,
   die eine Rechteprüfung erfordern?
5. Stufe jeden Fund nach OWASP-Kategorie und Ausnutzbarkeit ein
   (kritisch/hoch/mittel/niedrig).
Gib das Ergebnis als Tabelle mit Datei, Zeile, Kategorie, Einstufung und
konkretem Fix-Vorschlag aus."

5. Ein Review-Durchlauf am Beispiel

In der Praxis läuft ein solches Review meist zweistufig ab. Im ersten Schritt liefert Semgrep, integriert als CI-Job, eine Liste deterministischer Treffer, sortiert nach Regel-Schweregrad. Diese Liste dient Claude im zweiten Schritt als Ausgangspunkt: Statt bei null zu beginnen, kann das Modell angewiesen werden, jeden Semgrep-Treffer im Kontext der umgebenden Businesslogik zu bewerten und zusätzlich nach Mustern zu suchen, die Semgrep aufgrund fehlender Regeln gar nicht erst prüft.

Ein konkretes Beispiel aus der Praxis: Ein Pull Request fügt einen neuen Endpunkt zum Export von Nutzerdaten hinzu. Semgrep meldet keinen Treffer, weil die Query korrekt parametrisiert ist. Claude erkennt bei der Analyse des Aufrufpfads, dass die Autorisierungsprüfung nur die Existenz einer Session voraussetzt, nicht aber, ob die anfragende Person tatsächlich Zugriff auf die exportierten Datensätze haben darf. Genau diese Klasse von Fehlern, korrekte Syntax bei fehlerhafter Geschäftslogik, ist der eigentliche Mehrwert des Ansatzes.

6. Umgang mit False Positives und Priorisierung der Funde

Ein häufiges Missverständnis ist, ein Claude-gestütztes Review liefere automatisch weniger False Positives als ein regelbasierter Scanner. In der Praxis verschiebt sich das Problem eher: Statt struktureller False Positives, die aus zu allgemeinen Regeln entstehen, treten gelegentlich Fehleinschätzungen auf, bei denen das Modell einen Kontext falsch interpretiert, etwa eine Validierung übersieht, die in einer zentralen Middleware und nicht direkt am Endpunkt liegt.

Deshalb sollte jeder Fund mit einer nachvollziehbaren Begründung und einem konkreten Codepfad versehen sein, den ein Mensch in wenigen Minuten verifizieren kann, statt pauschale Warnungen ohne Beleg zu akzeptieren. Eine bewährte Praxis ist, Claude explizit um eine Konfidenzeinschätzung pro Fund zu bitten und Funde mit niedriger Konfidenz separat zu kennzeichnen, damit das Reviewer-Team die Priorisierung selbst steuert, statt jede gemeldete Zeile gleich zu behandeln.

7. Einbindung in die CI-Pipeline neben bestehenden SAST-Jobs

Für eine belastbare Integration in die Pipeline empfiehlt sich, das Claude-Review als eigenständigen, dem Semgrep-Job nachgelagerten Schritt zu betreiben, der dessen Ausgabe als zusätzlichen Kontext erhält. So bleibt der schnelle, deterministische SAST-Lauf als Pflicht-Gate erhalten, während das kontextuelle Review als ergänzender Kommentar im Pull Request erscheint, ohne den Merge bei jeder unsicheren Einschätzung zu blockieren.

Wichtig ist eine klare Trennung der Verantwortlichkeiten: Ein Semgrep-Treffer mit hohem Schweregrad sollte weiterhin den Merge blockieren, da die Regel deterministisch und gut verstanden ist. Ein Claude-Fund sollte zunächst als Kommentar mit Begründung erscheinen und von einer Person bestätigt werden, bevor er zum Blocker wird. Diese Abstufung verhindert, dass gelegentliche Fehleinschätzungen des Modells den gesamten Entwicklungsfluss aufhalten.

security-review:
  stage: test
  needs: ["semgrep-scan"]
  script:
    - semgrep_output=$(cat semgrep-results.json)
    - |
      claude -p "Bewerte den folgenden Diff (git diff origin/main) im Kontext
      dieser Semgrep-Funde: ${semgrep_output}. Ergänze Funde, die Semgrep
      aufgrund fehlender Kontextprüfung nicht erkennen kann, insbesondere
      Autorisierungslücken und fehlerhafte Geschäftslogik." \
      --output-format json > claude-review.json
  artifacts:
    paths:
      - claude-review.json

8. Grenzen: kein Ersatz für Pentests und deterministische Prüfungen

So wertvoll das kontextuelle Verständnis ist, ein Claude-gestütztes Review ersetzt weder einen Penetrationstest noch ein deterministisches SAST-Regelwerk. Die Ergebnisse eines Sprachmodells sind nicht bei jedem Lauf identisch, und bei sehr großen Diffs oder Repositories, die das verfügbare Kontextfenster übersteigen, kann relevanter Code schlicht außerhalb der betrachteten Dateien liegen und deshalb unentdeckt bleiben.

Auch bei tief verschachtelten Aufrufketten über viele Microservices hinweg, deren Code nicht vollständig im selben Repository liegt, stößt der Ansatz an Grenzen, weil das Modell nur analysieren kann, was ihm tatsächlich als Kontext vorliegt. Für regulierte Umgebungen mit Compliance-Anforderungen an lückenlose, auditierbare Prüfprotokolle bleibt deshalb eine Kombination aus deterministischem SAST, dediziertem Pentest und Claude-gestütztem Review die robusteste Strategie.

9. Etablierung im Team: Checkliste und Fazit

Für die Einführung im Team hat sich eine schrittweise Vorgehensweise bewährt: zunächst den bestehenden SAST-Lauf unverändert lassen, das Claude-Review parallel als reinen Kommentar-Schritt ohne Blockierwirkung einführen, über mehrere Wochen die Trefferqualität gemeinsam bewerten und erst danach entscheiden, welche Fundkategorien perspektivisch ebenfalls zum Blocker werden sollen.

Eine kurze Checkliste hilft beim Einstieg: Prompt so formulieren, dass er Datenfluss statt isolierter Zeilen betrachtet, Konfidenzangaben pro Fund einfordern, Semgrep-Ergebnisse als Kontext mitgeben, und die Verantwortung für die finale Freigabe stets bei einer Person belassen. So entsteht ein Review-Prozess, der die Geschwindigkeit klassischer SAST-Tools mit dem kontextuellen Verständnis eines Sprachmodells kombiniert, ohne eine der beiden Stärken zu verlieren.

10. Zusammenfassung

11. FAQ: SAST-ähnliche Security-Reviews mit Claude: Das Wichtigste auf einen Blick