Referenz-Harness zur Code-Verteidigung

Eine Referenzimplementierung für die autonome Erkennung und Behebung von Schwachstellen mit Claude, basierend auf unseren Erkenntnissen aus der Zusammenarbeit mit Sicherheitsteams mehrerer Organisationen seit dem Start von Claude Mythos Preview. Eine Zusammenfassung dieser Erkenntnisse samt Best Practices finden Sie im zugehörigen Blogbeitrag (auch verfügbar in blog-post.md). Für einen schlanken SDK-only-Durchlauf desselben recon → find → triage → report → patch-Zyklus siehe das begleitende Cookbook.

Dieses Repository wird nicht mehr gepflegt und es werden keine Beiträge mehr angenommen.

🔒 Möchten Sie eine verwaltete Option? Anthropic bietet Claude Security, ein gehostetes Produkt, das Schwachstellen in Ihrem Quellcode über mehrere Projekte hinweg findet und behebt. Claude Security scannt Ihr Repository auf Schwachstellen, wendet eine mehrstufige Verifizierungspipeline an, um Fehlalarme zu reduzieren, und ermöglicht es Ihnen, Befunde über ihren gesamten Lebenszyklus zu verwalten: Triage, Fix-Validierung und schnelle Fix-Generierung.

Dieses Repository ist eine Open-Source-Referenzimplementierung, die auf allgemeinen Best Practices zur Schwachstellensuche mit Claude basiert. Sie können es verwenden, um Ihre eigene Pipeline zur Schwachstellensuche aufzubauen, die Logik anzupassen, und es kann mit jedem Zugang verwendet werden, den Sie zu Claude-APIs haben (einschließlich Bedrock, Vertex oder Azure).

Inhalt

• Claude-Code-Skills: /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize: interaktive Eingrenzung, Scannen, Triage und Patching. Öffnen Sie dieses Repo in Claude Code und führen Sie /quickstart aus, um sich zu orientieren.
• harness/: die autonome Referenzpipeline (recon → find → verify → report → patch), konfiguriert für die Erkennung von C/C++-Speicherschwachstellen mit Docker und ASAN. Dieses Harness ist eine Referenz, kein Produkt. Die allgemeine Struktur, Prompts und Sandboxing sind wiederverwendbar, aber das Harness wird nicht auf jeder Codebasis sofort funktionieren. Führen Sie /customize aus, um es auf Ihre Sprache, Ihren Detektor oder Ihre Schwachstellenklasse zu übertragen.

⚠️ Sicherheit: /quickstart, /threat-model, /vuln-scan und /triage lesen und schreiben nur Dateien. Die Ausführung von /patch auf statischen Befunden (TRIAGE.json oder VULN-FINDINGS.json) ist ebenfalls nur lesend und schreibend. /customize bearbeitet den Harness-Code und führt Validierungsbefehle aus. Alle diese Skills können sicher ohne Sandbox ausgeführt werden, solange Sie jede Tool-Nutzung in Claude Code überprüfen und genehmigen. Die autonome Referenzpipeline (einschließlich /patch auf Pipeline-Ergebnissen) führt Zielcode aus, daher weigert sie sich, außerhalb einer gVisor-Sandbox zu laufen, sofern nicht explizit überschrieben. Zur Einrichtung führen Sie einmal scripts/setup_sandbox.sh aus und rufen Sie dann die Pipeline über bin/vp-sandboxed auf. Weitere Details finden Sie unter docs/security.md und .

Erste Schritte

git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claude

# 30-sec intro + guided first run on the canary target
> /quickstart

> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?

Weiterführende Literatur

• Blogbeitrag · Der zugehörige Blogbeitrag mit Erkenntnissen + Best Practices
• Pipeline · So funktioniert es: Diagramm, Phasen, CLI-Flags
• Sicherheit · Sandboxing, was nicht eingebunden werden sollte
• Agent-Sandbox · gVisor-Isolation + Egress-Allowlist für jeden Agenten
• Anpassen · Übertragung auf meinen Stack; welche Dateien sich ändern und warum
• Patching · Fixes für verifizierte Abstürze generieren und verifizieren
• Fehlerbehebung · Duplikate, Rate-Limits, Subagent-Modell-Pinning
• Schutzmaßnahmen · Block für gefährliche Cyber-Arbeit

Einarbeitung

Die erfolgreichsten Sicherheitsteams, mit denen wir zusammengearbeitet haben, sind diejenigen, die am schnellsten praktisch losgelegt haben. Auch wenn es verlockend ist, Monate mit der Entwicklung der perfekten Pipeline zu verbringen, empfehlen wir, am ersten Tag klein anzufangen und darauf aufzubauen, sobald Erkenntnisse vorliegen. Die folgenden Schritte folgen diesem Muster und geben ein ehrgeiziges (aber realistisches) Tempo vor, das auf dem basiert, was wir gesehen haben.

Schritt 1 (Tag 1): Erstellen Sie ein Bedrohungsmodell und führen Sie Ihren ersten statischen Scan + Triage durch

Tag 1 konzentriert sich darauf, den gesamten Zyklus von Anfang bis Ende zu sehen. Mit ausschließlich den interaktiven Skills erstellen Sie ein Bedrohungsmodell, führen einen statischen Scan durch, der dadurch eingegrenzt wird, führen für die zurückkommenden Ergebnisse eine Triage durch und entwerfen Kandidaten-Fixes. Sie beenden den Tag mit einem Bedrohungsmodell, einer priorisierten Liste statischer Befunde und Kandidaten-Patches.

Die relevanten Skills lesen und schreiben nur Dateien in Ihrem Repo. Solange Sie Claude Code interaktiv ausführen und jede Tool-Nutzung genehmigen, ist keine Sandbox erforderlich.

# Pin every subagent to the model you want
export CLAUDE_CODE_SUBAGENT_MODEL=<model-id>
claude

# 0. intro + guided first run
> /quickstart

# 1. Build a threat model (aim before you shoot)
> /threat-model bootstrap targets/canary

# 2. Run a static scan, scoped by that threat model
> /vuln-scan targets/canary

# 3. Verify, dedupe, and rank what came back
> /triage targets/canary/VULN-FINDINGS.json

# 4. Generate candidate fixes for the verified findings
> /patch ./TRIAGE.json --repo targets/canary

Dieser Ablauf erzeugt THREAT_MODEL.md, VULN-FINDINGS.{json,md}, TRIAGE.{json,md} und PATCHES/.

Die in Schritt 1 erzeugten Schwachstellenkandidaten stammen aus Claudes statischer Überprüfung des Quellcodes (es wird nichts gebaut oder ausgeführt), daher sind bei allen Nicht-Canary-Zielen mehr Fehlalarme zu erwarten. In Schritt 2 erzeugen Sie ausführungsverifizierte Befunde.

Hinweis: Beim Canary-Ziel kann /triage die Befunde des Scans als Fehlalarme verwerfen. entry.c kennzeichnet sich selbst als absichtlich verwundbaren Demo-Code, und /triage schließt Fehler in Test-/Fixture-Code korrekt aus. Um den vollständigen Bestätigungs-/Deduplizierungs-/Fehlalarm-Ablauf zu sehen, führen Sie ihn stattdessen auf dem kuratierten Fixture aus (/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary) oder richten Sie die Schritt-1-Skills auf Ihren eigenen Code.

Schritt 2 (Tag 2): Führen Sie die Referenzpipeline auf einer C/C++-Bibliothek aus

Am Tag 2 wechseln Sie von interaktiven Skills zu Ihrem ersten autonomen Lauf mit der Referenzpipeline. Sie führen den vollständigen recon → find → verify → report-Zyklus in Ihrer Umgebung auf einer bekanntermaßen verwundbaren Open-Source-Bibliothek aus und generieren anschließend einen Kandidaten-Patch für das, was sie findet. Sie beenden den Tag mit einem Satz reproduzierbarer Abstürze, Exploitability-Berichten und Kandidaten-Patches sowie einem Gefühl dafür, wie die Pipeline funktioniert.

Die Pipeline auszuführen ist einfach:

# One-time setup
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh   # installs gVisor, builds the agent images, and verifies isolation; note: requires Docker
export ANTHROPIC_API_KEY=sk-ant-...   # or CLAUDE_CODE_OAUTH_TOKEN, or Bedrock — see docs/agent-sandbox.md

# Run the recon → find → verify → report loop
bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus
# Generate a candidate patch for each finding
bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

# Or, ask Claude Code to launch the pipeline and watch the run for you
claude
> run the pipeline on drlibs and explain findings as they come

Die Ergebnisse des Zyklus landen in einem Verzeichnis results/drlibs/<timestamp>/. Mit dem Flag --stream erscheint der erste Bericht innerhalb von Minuten unter reports/bug_NN/.

⚠️ run startet autonome Agenten. Die Pipeline führt jeden Agenten in einem gVisor-Container aus, dessen ausgehender Datenverkehr auf die Claude-API beschränkt ist. Unterbefehle, die Agenten starten, weigern sich, außerhalb davon zu starten, sofern nicht explizit überschrieben. Weitere Informationen finden Sie unter docs/security.md und docs/agent-sandbox.md.

Im Hintergrund durchläuft die Pipeline sieben Phasen:

1. Build: Kompiliert das Ziel in ein Docker-Image mit ASAN (dem Speicherfehler-Erkenner für C und C++). Die Pipeline erstellt dieses Image beim ersten Lauf automatisch mithilfe des Dockerfiles des Ziels.
2. Recon: Ein leichtgewichtiger Agent liest den Quellcode in einem netzwerkisolierten Container und schlägt eine Partitionierung vor, d. h. „hier sind N verschiedene Eingabe-Parsing-Subsysteme, die es wert sind, separat angegriffen zu werden", sodass parallele Find-Agenten verschiedene Bereiche erkunden, statt auf demselben Fehler zu konvergieren. Ohne das Flag --auto-focus verwendet die Pipeline die Liste focus_areas aus der config.yaml des Ziels.
3. Find: N Agenten laufen parallel, jeder in seinem eigenen isolierten Container. Jeder Agent liest den Quellcode, erstellt fehlerhafte Eingaben und führt die ASAN-Binärdatei aus, bis eine bestimmte Eingabe 3 von 3 Mal einen Absturz verursacht.
4. Verify: Ein separater Grader-Agent reproduziert jeden Absturz in einem frischen Container, den der Find-Agent nicht berührt hat. Das Einzige, was vom Find-Agenten zum Grader übergeht, ist der Proof of Concept, den er erzeugt hat.
5. Dedupe: Ein Judge-Agent vergleicht verifizierte Abstürze mit bereits gemeldeten Fehlern und entscheidet, ob es sich jeweils um einen neuen Fehler, ein besseres Beispiel eines bekannten Fehlers oder ein zu überspringendes Duplikat handelt.
6. Report: Ein Report-Agent schreibt eine strukturierte Exploitability-Analyse pro eindeutigem Fehler, einschließlich Details zu Primitive-Klasse, Erreichbarkeit, Eskalationspfad und Schweregrad.
7. Patch (der separate Patch-Befehl oben): Ein Patch-Agent schreibt einen vorgeschlagenen Fix, und ein Grader-Agent bestätigt, dass der neue Code gebaut werden kann, dass die ursprüngliche Proof-of-Concept-Eingabe nicht mehr abstürzt, dass die Testsuite des Ziels weiterhin besteht und dass ein frischer Find-Agent keinen Weg um den Fix herum findet.

Weitere Details finden Sie unter docs/pipeline.md.

Schritt 3 (Tage 3-5): Passen Sie die Pipeline für Ihr Ziel an

An den Tagen 3-5 passen Sie das Harness für Ihr eigenes Ziel an. Zuerst richten Sie die Schritt-1-Skills auf Ihren Code und verwenden dann /customize, um die Pipeline auf Ihren Stack zu übertragen. Am Ende der Woche haben Sie ein Verzeichnis targets/<your-service>/, gegen das die Pipeline laufen kann, validiert mit einem einzigen Smoke-Test-Lauf der Pipeline und bereit für die Skalierung in Schritt 4.

Während die Referenzpipeline für die Erkennung von Speicherschwachstellen in C- und C++-Code entwickelt wurde, ist ihre Struktur generisch. Die Übertragung auf eine neue Schwachstellenklasse oder Sprache bedeutet lediglich, die folgenden Fragen für Ihren Ziel-Stack zu beantworten:

Bevor Sie anpassen, richten Sie die Schritt-1-Skills auf Ihren eigenen Code. Zur Erinnerung: Sie sind nur lesend und schreibend und können daher ohne Sandbox ausgeführt werden.

claude

> /quickstart how do I customize this for ~/code/my-service?

> /threat-model bootstrap-then-interview ~/code/my-service
> /vuln-scan ~/code/my-service
> /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service

Verwenden Sie dann die von diesen Skills erzeugten Artefakte im Skill /customize, der das Harness für Ihre Codebasis modifiziert.

> /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md

Wenn /customize abgeschlossen ist, haben Sie ein Verzeichnis targets/my-service/ eingerichtet. Validieren Sie es mit einem Smoke-Test-Lauf der Pipeline, bevor Sie skalieren.

bin/vp-sandboxed run my-service --model <model-id> --runs 1

Weitere Details finden Sie unter docs/customizing.md.

Schritt 4 (Woche 2): Starten Sie autonomes Scannen, Triage und Patching

In Woche 2 verwenden Sie die in Schritt 3 angepasste Pipeline auf Ihren eigenen Zielen und fügen dem inneren Pipeline-Zyklus einen äußeren Zyklus hinzu: mehrere Pipeline-Scans ausführen, die Befunde aus all diesen Läufen per Triage verwalten, basierend auf der Priorisierung patchen und wiederholen.

# Scan - run a wave of parallel runs against your target
bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus

# Triage - dedupe and rank every finding across all waves using your threat model
> /triage results/my-service/ --repo ~/code/my-service --auto --votes 5

# Patch - generate and validate fixes, starting with what triage ranked the highest
> /patch results/my-service/<timestamp>/ --model <model-id>

⚠️ Befolgen Sie die gleichen Sandboxing-Richtlinien wie in Schritt 2

Ein einzelner Pipeline-Lauf verifiziert und dedupliziert seine eigenen Befunde bereits. /triage arbeitet über viele Pipeline-Läufe hinweg. Wenn es auf das Verzeichnis results/ gerichtet ist, bereinigt es Duplikate über alle Läufe hinweg (sowie alle statischen Befunde von /vuln-scan, falls vorhanden), kalibriert die Schweregrad-Einstufungen anhand Ihres Bedrohungsmodells neu und versucht, jeden Befund dem Komponentenverantwortlichen zuzuordnen.

Wenn möglich, hilft das schnelle Patchen von Befunden, den äußeren Zyklus so produktiv wie möglich zu halten. Wenn Befunde behoben sind, kann das Modell sie nicht erneut finden und stößt stattdessen auf netto neue, typischerweise tiefere Probleme. Je mehr Pipeline-Wellen Sie ausführen, desto weniger Befunde wird es wahrscheinlich geben, aber die Komplexität wird wahrscheinlich ebenfalls zunehmen. Wenn schnelles Patchen nicht möglich ist, kann schon das bloße Erfassen früherer Befunde in den known_bugs des Ziels helfen, zukünftige Läufe auf neuere Fehler auszurichten.

Autonome Triage und autonomes Patching sind weiterhin offene Probleme, und dieses Referenz-Harness löst sie nicht vollständig. Die Verifizierungsstrategien in /patch helfen, die Messlatte höher zu legen, aber Schweregrad und Priorisierung sind letztlich Einschätzungen über Ihre Umgebung, und verifizierte Patches sind nicht immer upstreamfähig. Viele Partner haben diese Schritte als ihre derzeitigen Engpässe genannt, und Sie sollten echte Entwicklungszeit dafür einplanen.

Weitere Details finden Sie unter docs/triage.md und docs/patching.md.

Ausblick

Nach der anfänglichen Einarbeitung haben die Teams, mit denen wir zusammengearbeitet haben, dazu tendiert, in ein paar Richtungen zu investieren:

1. Überprüfung all ihrer internen Repositories und wichtigen Open-Source-Abhängigkeiten, Einstufung, welche am wichtigsten zu scannen sind (z. B. basierend auf ihrer Exposition, CVE-Historie, Geschäftskritikalität), und anschließendes Abarbeiten der Liste in Prioritätsreihenfolge.
2. Aufsetzen maßgeschneiderter Infrastruktur für das Scannen, um Scans von Laptops oder einmaligen VMs zu verlagern. Die erfolgreichsten Teams widerstehen dem Drang, die perfekte Scanning-Plattform zu bauen, bevor sie skalieren.
3. Integration von Scans in ihren SDLC. Einige Teams haben wiederkehrende Scans (z. B. täglich, wöchentlich) eingerichtet oder Scans in ihre CI-Pipelines aufgenommen.
4. Testen und Experimentieren mit den Modellen, um herauszufinden, was für sie am besten funktioniert.