[Musiker15]

Härtung des Security-Reviews nach einer Kritik am ersten Stand. Die Grundarchitektur bleibt (eigener Job zum Veröffentlichen, OIDC statt Schlüssel, pull_request_target ohne Ausführung, persist-credentials: false, angehefteter Commit); behoben ist, was an ihr vorbei ging.

Was die Kritik fand, und was sich ändert

1. Code aus dem PR lief im Job mit dem Recht auf ein Identity-Token. GitHub gibt ACTIONS_ID_TOKEN_REQUEST_* jedem Schritt eines Jobs mit id-token: write, also auch pnpm install und pnpm run build des PRs; dazu passwortloses sudo und offenes Netz. Jetzt:
   • Der Workflow installiert und baut nichts mehr. Die Shell des Agenten (nur bei PRs von Mitgliedern) läuft in der Sandbox von Claude Code: failIfUnavailable, allowUnsandboxedCommands: false, eigener Prozessraum (CLAUDE_CODE_SUBPROCESS_ENV_SCRUB), die Variablen des Tokens entfernt, Netz nur zu registry.npmjs.org, Lesen des Temp-Verzeichnisses des Runners gesperrt, Schreiben dort, in _actions und _tool gesperrt.
   • sudo ist abgeschaltet, bevor Claude Code startet; der Schritt bricht ab, wenn es noch geht.
   • Die Testdatenbank entfällt: die Sandbox hat ein eigenes localhost. Tests mit Datenbank laufen in der CI des PRs.
2. Write war nicht auf das Arbeitsverzeichnis begrenzt. Write, Edit und NotebookEdit sind jetzt verboten, Lesen ist mit blockReadsOutsideWorkingDirectories auf das Arbeitsverzeichnis begrenzt. Der Bericht ist die letzte Antwort des Agenten (Ereignis result im Stream), keine Datei mehr, die ein Test überschreiben könnte.
3. Einstellungen aus dem PR. Zu --safe-mode kommt --setting-sources user: eine .claude/settings.json im PR wird nicht geladen.
4. Vorbestehende Lücken standen im öffentlichen Bericht. Der Agent schreibt sie in einen eigenen Block; der Schritt "Bericht prüfen" nimmt ihn heraus (auch einen nicht geschlossenen), er kommt nicht ins Artefakt, und "Private Befunde als Code-Scanning-Alerts ablegen" lädt ihn als SARIF auf den Basiszweig hoch. Die Alerts sehen in einem öffentlichen Repository nur Personen mit Schreibrecht.
5. Insider. Ein Mitglied kann den Aufruf im eigenen PR ändern; der Status bleibt ein Signal gegen Fehler, kein Schutz gegen ein Mitglied. CODEOWNERS und eine Regel für .github/** sind eine eigene Entscheidung.

Der Job "Review" braucht dafür security-events: write; die Aufrufe geben es mit, wenn sie auf diesen Stand gehoben werden. Die Eingaben postgres-user und postgres-port entfallen.

Geprüft

• YAML lädt, die Textprüfungen der CI.
• Die Auswertung des Berichts lokal mit Beispieldaten: der private Block landet nicht im öffentlichen Bericht, ein nicht geschlossener Block führt zu "kein Bericht" statt zu einem Leck.
• Drei Testläufe an Security-Review in GitHub Actions aufrufen opengewerk-kanzlei#48 mit einem Prüfzweig, der dem Agenten Befehle gegen die Sandbox aufgab. Der letzte (Lauf 38068085142): keine Variablen des Tokens, Token-Datei und Temp-Verzeichnis nicht sichtbar, sudo gesperrt ("no new privileges"), example.com abgelehnt, vier Prozesse sichtbar, Schreiben außerhalb des Arbeitsverzeichnisses ohne Wirkung auf das echte Dateisystem. Der erste Lauf legte einen Testeintrag als Code-Scanning-Alert ab und nicht im Kommentar. Der zweite zeigte, dass eine Schreibsperre auf dem Home den Arbeitsbereich mit sperrt und bwrap dann nicht startet; die Sperre gilt seitdem nur für vorhandene Pfade unterhalb des Runners.
• Kosten der Testläufe 0,09 bis 0,12 USD.