nealbridges/vulnhunterAgentischer KI-Sicherheitsscanner, der wie ein Angreifer über den Quellcode schlussfolgert, ausnutzbare Schwachstellen mit ausführbaren PoCs bestätigt und testgetriebene Korrekturen über Hunt-, Fix- und Verify-Skills vorantreibt.
[!NOTE] Ein gepflegter Fork von Capital Ones VulnHunter (Apache-2.0) — entwickelt, um auf jedem Agent-Harness zu laufen, nicht nur auf Claude Code. Der Fokus dieses Forks: Harness-Portabilität, sandboxed (containerisierte) Exploit-Validierung und PoCs mit gemessener Auswirkung. Siehe Warum die Änderungen · Was dieser Fork ändert · Die Zahlen.
Vom Pattern-Matching zur Beweisbarkeit.
VulnHunter ist ein quelloffenes, agentisches KI-Sicherheitstool, das proaktive, angreiferorientierte Analysen direkt auf Quellcode anwendet.
Im Gegensatz zu traditionellen, passiven SAST-Scannern, die verdächtige Muster markieren und häufig Fehlalarme verursachen, denkt VulnHunter wie ein Angreifer. Es identifiziert, welche Defekte tatsächlich ausnutzbar sind, bildet mögliche Angriffspfade ab und schlägt gezielte, evidenzbasierte Korrekturen vor.
Moderne Software-Lieferketten sind tief miteinander verwoben. Eine einzelne Schwachstelle in einer weit verbreiteten Open-Source-Komponente kann sich gleichzeitig über Tausende von Unternehmen ausbreiten.
VulnHunter wurde intern bei Capital One entwickelt und für die Community als Open Source veröffentlicht. Dieser Fork führt diese Arbeit fort — dieselbe Methodik, überarbeitet, um auf jedem Agent-Harness zu laufen, mit sandboxed (containerisierter) Exploit-Validierung und PoCs mit gemessener Auswirkung als Roadmap. Siehe Was dieser Fork ändert.
Dual-Use-Warnung VulnHunter führt Dual-Use-Cybersicherheitsarbeit durch (Schwachstellenerkennung und -ausnutzung). Rechnen Sie mit Schutzmechanismen: Die meisten kommerziell verfügbaren Modelle wenden Dual-Use-Cyber-Schutzmaßnahmen an, und aggressives Ausnutzungsverhalten kann Ratenlimits oder Nutzungskennzeichnungen auslösen. Entwicklung und Tests von VulnHunter liefen auf offenen, von der Community bereitgestellten Modellen — de-risked, abliterated und unzensiert —, die für den organisatorischen Einsatz künftig wahrscheinlich relevant sein werden. Prüfen Sie nur Code, den Sie besitzen oder zu dessen Prüfung Sie anderweitig berechtigt sind.
[!IMPORTANT] Voraussetzungen & Modellanforderungen Die Methodik von VulnHunter ist darauf ausgelegt, auf offenen, von der Community bereitgestellten Modellen zu laufen — den de-risked, abliterated, unzensierten Modellen, die Organisationen tatsächlich einsetzen können. Ein leistungsfähiges Reasoning-Modell ist erforderlich; das stärkste Modell, das Ihr Harness bietet, liefert die besten Ergebnisse, aber die Methodik hängt nicht von einem Frontier-Modell eines bestimmten Anbieters ab. Sie stellen Ihren eigenen Modellzugang bereit.
| Fähigkeit | Upstream (Capital One) | Dieser Fork | Status |
|---|---|---|---|
| Harness-Portabilität | Skills rufen speziell Claude Code auf; der Installer zielt auf ~/.claude/skills; Modell-Gates hardcodieren Opus; das Harness pinnt claude-opus-4-8 | Skills sind harness-portable Prompt-Dateien (jedes Harness mit einem Skills-Verzeichnis + Subagenten); Umgebungsvertrag VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL; Modell-Gates umformuliert zu „das leistungsfähigste Reasoning-Modell deines Harness“ | Ausgeliefert |
| No-Guess-Installer | install.sh geht von ~/.claude/skills aus | Explizite Verzeichnisse, respektiert GROK_HOME-Semantik, schreibt den vh-Launcher nach VULNHUNT_BIN_DIR/~/.local/bin, installiert den vulnhunter-run-Skill + die Agent-Definition; Windows-.cmd-Äquivalente aktualisiert | Ausgeliefert |
vulnhunter-run-Operator-Skill | — (nicht vorhanden) | Unbeaufsichtigter Operator: Klonen → Jagen → Ergebnisse finden → das Scan-Manifest schreiben/validieren, mit expliziten Abbruchregeln und ohne Improvisation | Ausgeliefert |
| Benchmark-/Judge-Härtung | Festes Modell + einfacher Retry | Modell über Umgebung, Retry-/Backoff-Konfiguration, analyze_misses-Pipeline-Verlustpunkt-Verfolgung, Verlaufsverfolgung pro Finding | Ausgeliefert |
| Harness-neutraler Berichtssprache | Claude-spezifische Prosa durchgängig in den Skills | Harness-neutrale Tool-Sprache (Agent → Subagent, Claude CLI → Harness-Sitzung) | Ausgeliefert |
| Sandbox-first Exploit-Validierung | Exploit-Tests können statische Traces sein; Laufzeitwahl ad hoc | Docker-first Laufzeitbereitstellung; die Laufzeit pro Finding erfasst; Schweregrad Medium+ muss ausgeführt werden | In Arbeit |
| PoCs mit gemessenem Impact | PoCs sind Dokumente; Impact wird behauptet | Ausführbarer PoC + Impact-Zahl im Finding (offengelegte Zeilen, verstärkte Anfragen, gebundene Schlüsselstunden) | In Arbeit |
VulnHunters Methodik ist von Natur aus host-agnostisch: Sie ist Prompt-Prozedur, keine Tool-Bindung. Das Upstream-Projekt wuchs innerhalb von Claude Code heran — eine kohärente Wahl und das richtige erste Zuhause. Doch die Landschaft der Agent-Harnesses hat sich verbreitert, und eine Sicherheitsmethodik, die sich nur in einen davon installieren lässt, hört auf, eine Audit-Fähigkeit zu sein, und wird zu einem Vendor-Feature. Dieser Fork nimmt vier Änderungen vor, jede mit einem Grund.
Jeder Skill hier ist eine portable Prompt-Datei mit einem expliziten Umgebungsvertrag (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD), und die Modell-Gates fragen nun nach dem leistungsfähigsten Reasoning-Modell deines Harness statt nach einem bestimmten Produkt. Besser bedeutet: Dieselbe Methodik installiert sich in welches Harness dein Team auch immer bereits betreibt — und wird in Benchmark-Läufen über Harnesses hinweg vergleichbar, was der Art und Weise entspricht, wie dieser Fork entwickelt wird.
Der Upstream-Installer kopierte Skills bedingungslos nach ~/.claude/skills. Auf einer Maschine, die zwei Harnesses betreibt — oder ein Harness mit einem verlegten Home-Verzeichnis —, installiert diese Annahme stillschweigend am falschen Ort. Der Installer des Forks fragt nach oder nimmt Umgebungsvariablen entgegen und schlägt lautstark mit der exakten Anweisung fehl, wenn die Antwort fehlt. Besser bedeutet: sicher auf Multi-Harness-Maschinen, korrekt bei verlegten Home-Verzeichnissen, laut statt still bei Fehlkonfiguration.
Das ursprüngliche Design verlangt bereits Falsifikations- und Exploit-Tests. Offen blieb, wie hart man arbeiten muss, um sie tatsächlich auszuführen: statischer Trace, gemockter Test oder ein echter containerisierter Server. In einem Benchmark mit sechs Durchläufen gegen einen einzigen Commit führte dieser Ermessensspielraum zu irgendwo zwischen 3 und 42 Findings — und zu gegensätzlichen Urteilen über dieselbe Sink, eines gegen einen Mock bewiesen, eines durch einen Test gegen einen echten Server geschlossen. Dieser Fork fügt ein Verfahren zur Laufzeitbereitstellung hinzu (Docker-first, pro Finding protokolliert) sowie eine PoC-Disziplin, bei der die Auswirkung gemessen wird — geleakte Zeilen, ×-Verstärkung, verlorene Schlüsselstunden — nicht erzählt. Besser bedeutet: Die Gültigkeit eines Findings hängt nicht länger davon ab, welches Modell den Instinkt hatte, einen Container hochzufahren. (In Arbeit — der Build-Plan steht auf der öffentlichen Roadmap; frag in den Issues nach oder beobachte die Discussions des Repos.)
