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 One's 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 Wirkung. Siehe Warum die Änderungen · Was dieser Fork ändert · Die Zahlen.
Von Pattern-Matching zur Beweisbarkeit.
VulnHunter ist ein quelloffenes, agentisches KI-Sicherheitstool, das proaktive, angreiferorientierte Analyse direkt auf Quellcode anwendet.
Im Gegensatz zu traditionellen, passiven SAST-Scannern, die verdächtige Muster melden und oft Fehlalarme verursachen, denkt VulnHunter wie ein Angreifer. Es identifiziert, welche Defekte tatsächlich ausnutzbar sind, kartiert potenzielle Angriffspfade 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 Wirkung als Roadmap. Siehe Was dieser Fork ändert.
Dual-Use-Warnung VulnHunter führt Dual-Use-Arbeiten im Bereich Cybersicherheit 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 Nutzungsflags auslösen. Die Entwicklung und Tests von VulnHunter liefen auf offenen, von der Community bereitgestellten Modellen — de-risked, abliterated und unzensiert —, die wahrscheinlich für die organisatorische Nutzung in Zukunft relevant sein werden. Prüfen Sie nur Code, den Sie besitzen oder anderweitig zur Prüfung autorisiert 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, 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 bestimmten Frontier-Modell eines Anbieters ab. Sie stellen Ihren eigenen Modellzugang bereit.
| Fähigkeit | Upstream (Capital One) | Dieser Fork | Status |
|---|---|---|---|
| Harness-Portabilität | Skills rufen spezifisch Claude Code auf; Installer zielt auf ~/.claude/skills; Modell-Gates hardcodieren Opus; Harness pinnt claude-opus-4-8 | Skills sind harness-portable Prompt-Dateien (jedes Harness mit einem Skills-Verzeichnis + Subagenten); VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL Umgebungsvertrag; Modell-Gates umformuliert zu "das leistungsfähigste Reasoning-Modell Ihres Harness" | Ausgeliefert |
| No-Guess-Installer | install.sh geht von ~/.claude/skills aus | Explizite Verzeichnisse, beachtet GROK_HOME-Semantik, schreibt den vh-Launcher nach VULNHUNT_BIN_DIR/~/.local/bin, installiert das vulnhunter-run-Skill + Agent-Definition; Windows-.cmd-Äquivalente aktualisiert | Ausgeliefert |
vulnhunter-run-Operator-Skill | — (nicht vorhanden) | Unbeaufsichtigter Operator: Klonen → Jagen → Ergebnisse finden → Scan-Manifest schreiben/validieren, mit expliziten Stoppregeln und ohne Improvisation | Ausgeliefert |
| Benchmark/Judge-Härtung | Festes Modell + einfacher Retry | Modell über Umgebung, Retry/Backoff-Konfiguration, analyze_misses-Pipeline-Verlustpunktverfolgung, Verlaufserfassung pro Finding | Ausgeliefert |
| Harness-neutrale 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; Medium+ Schweregrad muss ausgeführt werden | In Arbeit |
| PoCs mit gemessener Wirkung | PoCs sind Dokumente; Wirkung behauptet | Ausführbarer PoC + Wirkungszahl im Finding (exponierte Zeilen, verstärkte Anfragen, gestrandete Key-Stunden) | In Arbeit |
Die Methodik von VulnHunter 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. Aber die Agent-Harness-Landschaft hat sich erweitert, und eine Sicherheitsmethodik, die sich nur in eine davon installiert, hört auf, eine Audit-Fähigkeit zu sein, und wird zu einem Anbieter-Feature. Dieser Fork nimmt vier Änderungen vor, jede mit einem Grund.
Jedes 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 jetzt nach dem leistungsfähigsten Reasoning-Modell Ihres Harness statt nach einem bestimmten Produkt. Besser bedeutet: Dieselbe Methodik installiert sich in welches Harness Ihr Team auch immer bereits betreibt — und wird in Benchmark-Läufen über Harnesses hinweg vergleichbar, was die Art und Weise ist, wie dieser Fork entwickelt wird.
Der Upstream-Installer kopierte Skills bedingungslos nach ~/.claude/skills. Auf einer Maschine, die zwei Harnesses ausführt — oder ein Harness mit einem verlegten Home — installiert diese Vermutung still und leise am falschen Ort. Der Installer des Forks fragt nach, oder nimmt Umgebungsvariablen, und schlägt laut mit der exakten Anweisung fehl, wenn die Antwort fehlt. Besser bedeutet: sicher auf Multi-Harness-Maschinen, korrekt unter verlegten Homes, laut statt still bei Fehlkonfiguration.
Das ursprüngliche Design verlangt bereits Falsifikation und Exploit-Tests. Was es offen ließ, war wie hart gearbeitet werden muss, um sie tatsächlich auszuführen: statischer Trace, gemockter Test oder ein echter containerisierter Server. In einem Sechs-Lauf-Benchmark gegen einen einzelnen Commit produzierte dieses Ermessen zwischen 3 und 42 Findings — und gegensätzliche Urteile zum selben Sink, eines gegen einen Mock bewiesen, eines durch einen Test gegen einen echten Server geschlossen. Dieser Fork fügt eine Laufzeitbereitstellungsprozedur hinzu (Docker-First, pro Finding erfasst) und eine PoC-Disziplin, bei der die Wirkung gemessen wird — geleakte Zeilen, ×-Verstärkung, gestrandete Key-Stunden — nicht erzählt. Besser bedeutet: Die Gültigkeit eines Findings hängt nicht mehr davon ab, welches Modell den Instinkt hatte, einen Container hochzufahren. (In Arbeit — der Build-Plan ist auf der öffentlichen Roadmap; fragen Sie in Issues oder beobachten Sie die Discussions des Repos.)
