Mein claude-workflow-kit hat einen Review-Skill. Er liest den Code, bevor ich pushe. Eine Frage höre ich dazu immer wieder: Warum prüft dieser Skill nicht gleich die Sicherheit mit? Das Modell liest den Code ohnehin. Es könnte nebenbei nach Secrets und Injection-Lücken suchen.

Genau das tut es nicht. Mit Absicht.

Kurz zum Werkzeug. Das claude-workflow-kit sind zehn Skills für Claude Code, von der Planung über Issues und Implementierung bis zum Review. Dazu drei Stop-Punkte, die ich bewusst nicht automatisiere: das GO, der Push, der Merge. Der Review-Skill ist einer dieser zehn. Er ist nützlich. Aber er ist ein Sprachmodell. Und Sicherheit gehört nicht in die Hand eines Sprachmodells.

Der gemeinsame blinde Fleck

Ein Modell, das Code reviewt, stammt aus derselben Quelle wie das Modell, das den Code geschrieben hat. Dieselben Trainingsdaten, dieselben Muster, dieselben blinden Flecken. Wenn ein Modell ein Secret hartkodiert, weil dieses Muster in seinen Daten oft vorkam, dann ist dasselbe Muster auch im Review unauffällig. Ich bitte den Fuchs, den Hühnerstall zu bewachen.

Ein Beispiel. Das Modell baut den Benutzernamen per String-Konkatenation in ein SQL-Statement. Das ist eine klassische Injection-Lücke. Frage ich dasselbe Modell, ob der Code sicher ist, höre ich oft, alles sei in Ordnung. Nicht aus Bosheit. Es hat das Muster geschrieben, weil es ihm vertraut ist, und es liest dasselbe Muster im Review als vertraut.

Ein deterministisches Tool teilt mit keinem Sprachmodell einen blinden Fleck. Es denkt nicht. Es gleicht ab. gitleaks sucht nach Mustern, die wie Secrets aussehen, und findet sie, egal ob ein Modell sie für harmlos hält. semgrep und spotbugs finden genau diese String-Konkatenation im SQL und die fehlende Input-Validation, weil die Regel in der Konfiguration steht. Nicht in einem Kontextfenster, das sich im Lauf einer langen Sitzung verwässert.

Dann eben ein anderes Modell

Jetzt kommt der Einwand: Dann reviewe ich eben mit einem zweiten Modell. Anderer Hersteller, andere Trainingsdaten, anderer blinder Fleck.

Stimmt zum Teil. Ein zweites Modell setze ich ein, und ich halte es für sinnvoll. Gegen das Sicherheitsproblem hilft es trotzdem nur halb.

Erstens überlappen die blinden Flecke mehr, als der Einwand annimmt. Hartkodierte Secrets und per String gebaute SQL-Statements stehen in jedem öffentlichen Repository millionenfach. Dieses Muster steckt in den Trainingsdaten von Modell A und in denen von Modell B. Ein anderer Hersteller ist nicht automatisch ein anderer blinder Fleck.

Zweitens gibt ein zweites Modell eine zweite Meinung. Keine Garantie. Heute findet es die Lücke, morgen bei leicht anderem Prompt nicht. Das Ergebnis ist nicht wiederholbar. gitleaks findet dasselbe Secret bei jedem Lauf, jedes Mal, ohne Ausnahme. Das ist kein Vorteil im Durchschnitt. Das ist eine andere Kategorie.

Drittens löst ein zweites Modell das Durchsetzungsproblem nicht. Es gibt einen Hinweis, keinen roten Build. Es blockiert den Push nicht. Wer ein zweites Modell zum Sicherheitsgate erklärt, hat die Prüfung verbessert und die Verbindlichkeit nicht angefasst.

Ein roter Build blockiert mechanisch

Der zweite Unterschied ist die Verbindlichkeit. Ein Skill gibt einen Hinweis. Ein Hinweis lässt sich übergehen, besonders wenn es eilt. Ein roter Build lässt sich nicht übergehen, ohne ihn grün zu machen.

Dieselbe Mechanik setze ich schon bei Architekturregeln ein. Wer ArchUnit als Test formuliert, bekommt von der KI keinen Code mehr, der die Schichtengrenzen verletzt. Der Build schlägt fehl, die KI muss es richtig machen. Sicherheit ist nichts anderes. Die Regel steht im CI, der Build entscheidet, niemand diskutiert.

Das ist auch der Grund, warum diese Prüfung außerhalb der Sitzung laufen muss. Ein Skill läuft im Dialog mit dem Modell, mit allem, was dazugehört: dem Drang, hilfreich zu sein, dem Kontext, der gegen Ende kippt, der Bereitschaft, einen Einwand wegzuargumentieren. Ein CI-Job läuft jedes Mal gleich. Ohne Gedächtnis, ohne Stimmung, ohne Meinung.

Was der Skill kann und was nicht

Der Review-Skill bleibt. Er ist gut bei den Dingen, die ein Urteil brauchen: Lesbarkeit, Namensgebung, fehlende Tests, unklare Abstraktionen, eine Funktion, die zu viel auf einmal tut. Das ist Arbeit, für die ein Sprachmodell taugt.

Sicherheit braucht kein Urteil. Sicherheit braucht eine Regel, die abgleicht, und einen Build, der blockiert. Beides ist deterministisch, beides ist wiederholbar, beides ist unabhängig vom Modell, das den Code geschrieben hat. Der Skill ergänzt diese Tools. Er ersetzt sie nicht.

Wer das verwechselt, baut sich ein Sicherheitsgefühl. Kein Sicherheitsnetz.