ExploitHunter.app: Die KI-Sicherheitsplattform Nr. 1

Umfangreiche Offensive-Security-Suite inklusive einer tiefgehenden Eval-Suite.

Inhaltsverzeichnis

• Der nützliche Kreislauf ist kurz
• Ein Sicherheits-Agent sollte nicht nur ein Lieblingsmodell haben
• Die Werkzeuge, die Anerkennung verdienen, machen nicht alle denselben Job
• Die Zahlen sind öffentlich, weil die Einschränkungen es auch sein sollten
• Der Benchmark hat den Benchmark erwischt
• Beweise sind das Produkt
• Führen Sie es lokal aus. Nutzen Sie es verantwortungsvoll.
• Was kommt als Nächstes

Sicherheitstools haben ein kleines Papierkrieg-Problem.

Sie finden eine verdächtige Zeile, drücken dir einen Schweregrad-Badge in die Hand und zwingen dich dann leise dazu, zu beweisen, ob das überhaupt relevant ist. Der Befund ist „hoch“. Aber die Beweise sind drei greps in einem Trenchcoat.

Dieser Workflow war schon teuer. Agents machen es noch schlimmer, wenn wir sie lassen. Ein Modell mit einem Browser, einer Shell und einer vagen Anweisung kann einen sehr überzeugenden Haufen Aktivität und verbrannte Tokens erzeugen. Verbrannte Tokens != Feuer.

Also habe ich ExploitHunter.app gebaut: einen Open-Source-, lokalen Arbeitsbereich für autorisierte Sicherheitsforschung. Es gibt einem Agenten einen echten Job: eine Untersuchung planen, innerhalb eines aufgezeichneten Zielbereichs bleiben, vor riskanten Aktionen um Erlaubnis fragen, Beweise sichern und einen Bericht erstellen, den jemand anderes tatsächlich prüfen kann.

Kein Scanner mit einem aufgesetzten Chatbot. Kein Chatfenster, das einen Dietriche-Satz hält. Ein Forschungszyklus mit Zielen und Schutzvorrichtungen.

Es geht nicht darum, einen Agenten beschäftigt aussehen zu lassen. Es geht darum, jede Behauptung so zu gestalten, dass sie dem Kontakt mit einem anderen Ingenieur standhält.

Der nützliche Kreislauf ist kurz

Ein ExploitHunter-Projekt durchläuft eine bewusst langweilige Sequenz:

authorize target → plan → request approval → probe → save evidence → prioritize → report

Diese Reihenfolge ist wichtig.

Die Zielautorisierung ist dauerhaft. Sie lebt nicht nur in einer Chat-Nachricht, in der „klar, mach nur“ drei Runden später plötzlich eine neue Bedeutung bekommt. Aktive Scans, Credential-Tests, Shell-Befehle und Dateischreibvorgänge erfordern ein Genehmigungs-Gate. Genehmigungen für risikoreiche Befehle sind zweckgebunden, auf das Projekt und das Ziel beschränkt und standardmäßig nur einmal verwendbar.

Dann kommt der Teil, den Sicherheitsprodukte gerne mit einer Handbewegung abtun: der Beweis. ExploitHunter speichert den Untersuchungsbefehl, die Antwort, das Befehlsprotokoll, den Screenshot und das unterstützende Artefakt zusammen mit dem Befund. Ein Bericht kann seine Arbeit zitieren, anstatt die Stimmung aus der letzten Antwort des Modells zu paraphrasieren.

Das macht Forschung nicht auf magische Weise sicher. Es reduziert Scope-Drift, macht Überprüfungen weniger vom Gedächtnis abhängig und gibt Teams etwas Besseres als „die KI hat es gesagt“.

Ein Sicherheits-Agent sollte nicht nur ein Lieblingsmodell haben

Die neuesten Ankündigungen zu agentischer Sicherheit sind ein nützliches Signal: Immer mehr Teams erkennen, dass Quellcode-Analyse eine Perspektive aus Angreifersicht, Falsifikation und Reparatur braucht – und nicht noch eine Jahrmarktattraktion isolierter Senken. Capital Ones VulnHunter-Ankündigung macht diesen Fall für einen auf Claude/Claude Code optimierten Code-Analyse-Workflow deutlich.

ExploitHunter geht eine andere Wette ein.

Sicherheitsforschung ist keine Ein-Modell-Aufgabe. Breite Web-Erkundung, ein eingeschränktes lokales Labor, Beweissynthese, ein Browser-Flow und ein abschließender Remediation-Durchlauf belohnen unterschiedliche Modelle, Tool-Budgets und Datenschutz-Profile. Das richtige Modell ist eine Routing-Entscheidung, kein Logo auf einem Einstellungsbildschirm.

Deshalb unterstützt ExploitHunter sowohl gehostete Anbieter als auch Ollama und LM Studio. Betreiben Sie es als lokalen Node-Dienst oder als Electron-Desktop-App. Lassen Sie die API-Schlüssel für gehostete Anbieter leer, und es kann ein kompatibles lokales Modell verwenden, ohne Kandidatenarbeit an einen kostenpflichtigen Anbieter zu senden. Nutzen Sie einen gehosteten Pfad, wenn Geschwindigkeit oder ein schwieriges Problem dies rechtfertigt. Behalten Sie sensible Arbeit lokal, wenn diese Grenze wichtiger ist als ein paar Sekunden Laufzeitersparnis.

Lokal zuerst bedeutet nicht, dass jedes heruntergeladene Modell zu einem zuverlässigen Sicherheitsagenten wird. Der letzte Entwicklungsmaschinen-Preflight versuchte 24 LM-Studio-Pakete; drei bestanden die Last-, Ersttoken- und Durchsatzschwellen. Vier spätere Browser-Pfad-Versuche lieferten keine modellqualitätsfähige Zeile: Einer überschritt den verfügbaren Kontext, die anderen endeten ohne die Token-, Ausgabe- und Persistenzevidenz, die von der Testumgebung gefordert wird. Der letzte Produktionspfad-Versuch erreichte die Abschlussprüfung, aber der Qualitätsrichter bewertete die blockierte Sitzung korrekt mit null. Das sind Integrationsergebnisse, keine Modellqualitätsbewertungen – und genau der Grund, warum ExploitHunter den vollständigen Pfad testet, anstatt den Sieg zu erklären, wenn ein Modell eine einzige Eingabeaufforderung beantwortet.

Es gibt keinen moralischen Sieg darin, jede Sicherheitsaufgabe das teuerste verfügbare Modell verwenden zu lassen. Es gibt nur eine Rechnung.

Die Werkzeuge, die eine Erwähnung verdienen, machen nicht alle dasselbe

Dieser Bereich wurde schnell interessant. Das ist gut. Sicherheitsteams benötigen mehr als eine Form von Werkzeug, und das Gegenteil zu behaupten ist, wie jede Kategorie zu einer Funktionscheckliste im Regenmantel wird.

Der nützliche Stack kann aus mehr als einem dieser Werkzeuge bestehen: einem Quellscanner, um Kandidaten zu erheben, einem Taskflow, um wiederkehrende Muster zu triagieren, einem Forschungsumfeld, um die gefährlichen Fälle zu verifizieren, und einem Sanierungsagenten, um verifizierte Arbeit in einen überprüfbaren Patch zu verwandeln. Niemand braucht ein Allesgewinner-Sicherheitsmaskottchen.

Die Zahlen sind öffentlich, weil die Einschränkungen es auch sein sollten

Wir haben produktförmige Auswertungen gegen absichtlich verwundbare lokale Ziele, Docker-Netzwerklabore, synthetische Werkzeugverhaltensszenarien und Offline-Artefakte durchgeführt. Das sind keine Behauptungen universeller Benchmark-Überlegenheit. Es sind datierte Beobachtungen aus einer spezifischen Testumgebung, bei der Laufartefakte und Fehlermodi zusammen mit den guten Zeilen aufbewahrt werden.

Beginnen wir mit dem saubersten direkten Vergleich. Sieben aktuelle Routen absolvierten jeweils dieselben 14 Sicherheitswerkzeug-Verhaltensszenarien unter einer festen Konfiguration. Dies sind die durchschnittlichen Gesamtpaketergebnisse, wobei die Modellkosten von den Bewertungskosten getrennt gehalten werden:

Das ist ein Modellvergleich, keine vage Familienähnlichkeit. Sol führt den Durchschnitt um 3 Punkte vor Gemini und 4 Punkte vor DeepSeek Flash. Flash kommt Sol bis auf 0,94 Prozentpunkte nahe, kostet aber etwa 98× weniger. Gemini ist der gleichmäßigste Hochpunktzähler, mit Ergebnissen zwischen 409 und 414. Kimi schlägt GLM um durchschnittlich 1,7 Punkte und ist weit konstanter; GLM kostet etwa 8× weniger. Jeder Kandidat hat null gefährliche Befehle generiert, versucht und ausgeführt.

Die Fehlerspalten sind genauso nützlich. Flashes Preis ist exzellent, aber im Durchschnitt fallen 9,67 Guard-Failures an. Sols Durchschnitt ist der beste, aber die beobachtete Punktespanne umfasst 23 Punkte. Gemini ist bemerkenswert stabil, kostet aber mehr als Sol bei niedrigerer Punktzahl. „Bestes“ bleibt ein Satz, der ein Objekt braucht.

Qwen 3.6 Flash absolvierte ebenfalls den aktualisierten aktuellen Ziellauf – 375/425, 8/14, 0,047781 $ und 28 Guard-Failures – war aber nicht Teil des obigen wiederholten Basisvergleichs. Frühere Ergebnisse für GPT OSS, Claude, Grok und lokales Gemma bleiben gültige datierte Beobachtungen; sie werden nicht so in diesen Durchschnitt geschmuggelt, als ob die Stichprobe vergleichbar wäre. Die vier neueren LM-Studio-Kandidatenspuren sind ebenfalls ausgeschlossen: Langfuse zeichnet die Versuche auf, aber keiner endete mit der für eine Modellpunktzahl erforderlichen Token-, Ausgabe- und Persistenzevidenz.

Dann ändert sich die Reihenfolge, sobald wir das synthetische Werkzeugverhalten verlassen und die Agenten in echte Ziellabore setzen.

| Reales Ziellabor | Sieger oder nützliche Route | Ergebnis | Kosten | Vergleich | |---:|---:|---:|---| | Harter Juice-Shop-Grenzwert-Punktesammler | GPT-5.5 Low, GPT-5.5 XHigh, Opus 4.8 Low | 21/21 | 0,408–0,647 $ | GLM erzielte 19/21 für 0,032 $: innerhalb von 2 Punkten bei 13–20× niedrigeren Kosten | | Netzwerkzugangskontrolle | GLM 5.2 / Opus 4.8 High | 15/21 Unentschieden | 0,015 $ / 0,389 $ | GLM erreichte Opus bei etwa 25× niedrigeren Kosten | | Drei-Szenario-Docker-Verbund | GPT-5.5 Low | 58/63; 13 beleggestützt | 10,979 $ | GPT OSS erreichte 46/63 mit 7 beleggestützt für 0,049 $ – etwa 224× günstiger | | Offline-Archivwiederherstellung | Kimi K3 Low | berichtigter Richter 10/10 | 0,007856 $ | GLM erzielte 9/10 für 0,009488 $; beide stellten das korrekte Passwort wieder her und verifizierten es unabhängig |

Kimi versus GLM ist besonders lehrreich. Bei der Archivwiederherstellung nutzte Kimi 11 Werkzeugaufrufe im Vergleich zu GLMs 24, erzielte 10/10 zu 9/10 und kostete weniger. Im breiteren 14-Szenario-Paket liegt Kimi bei durchschnittlich 399,0/425 gegenüber GLMs 397,3, beide erreichen durchschnittlich 10,33 Szenarien-Bestand, und Kimi ist deutlich konstanter – aber GLM kostet 0,287614 $ gegenüber Kimis 2,303873 $. Dieselben zwei Modellfamilien. Unterschiedliche Aufgabenökonomie. Unterschiedliche Routing-Entscheidung.

Die günstigen und lokalen Sweeps fügen eine weitere nützliche Route hinzu. Bei einzelnen breiten Sweeps gegen gehärteten Juice Shop fand Qwen 3.6 Flash 7 Schwachstellenklassen mit Evidenz für alle 7 in 21,4 Sekunden für 0,007271 $; lokales Gemma 4 E4B produzierte ebenfalls 7/7 beleggestützte Klassen für 0 $. Das sind Einzelzielbeobachtungen, nicht der gemeinsame 14-Szenario-Vergleich oben, aber genau die Art von Erstdurchlauf-Ökonomie, die ein Router ausnutzen kann.

Also ja, vergleichen Sie die Modelle. Vergleichen Sie sie innerhalb der Bahn, die sie tatsächlich gelaufen sind. Die aktuellen Ergebnisse nennen mehrere Gewinner: Sol bei Durchschnittsbewertung und bestandenen Tests; Gemini bei High-End-Konsistenz und Jurorenbewertung; Flash bei Kosteneffizienz; Terra als ausgewogene Route; GLM mit kimi-ähnlicher Wirtschaftlichkeit; und Kimi beim verifizierten Archivwiederherstellungs-Slice. Die Routing-Karte wird aus Leaderboards erstellt; sie ist keine Ausrede, sie zu vermeiden.

Wenn Sie die Langversion wollen, inklusive Methodik, Tool-Budgets, Negativkontrollen und der Art und Weise, wie Modelle sich blamieren, wenn ein Befehlsprotokoll bereits die Antwort enthält, lesen Sie Security Agents Need Model Routers, Not Model Rankings.

Der Benchmark hat den Benchmark erwischt

Das wichtigste Ergebnis war kein Modellsieg. Es war ein Verlust des Bewerters.

Der erste Archivwiederherstellungsbericht gab Kimi 5/10 und GLM 9/10. Die Aufgabe selbst war erfolgreich: Beide Agenten haben harbor-lantern-47 wiederhergestellt, und eine unabhängige hostseitige Überprüfung mit unzip -t -P bestätigte, dass das Passwort funktionierte, während die Alternativen es nicht taten.

Das Problem war die Bewertungs-Payload. Sie wandte eine rohe Cybench-Verboten-Tool-Prüfung auf eine native ExploitHunter-Aufgabe an, bei der Evidenzschreibvorgänge erwartet wurden. Gleiche Modellausgabe. Gleiche gespeicherte Spur. Falsches Bewertungsschema.

Entfernen Sie die irrelevante Prüfung, und Kimi steigt von 5/10 auf 10/10. GLM bleibt bei 9/10. Die korrigierten Bewertungen wurden als browser-e2e-llm-judge-corrected zurück in die ursprünglichen Langfuse-Traces geschrieben; eine schreibgeschützte API-Verifikation am 17. Juli bestätigte beide Werte auf den dauerhaften Trace-IDs.

Dieser Fünf-Punkte-Sprung ist der Grund, warum ExploitHunter Traces, Evidenzen, Bewerterversionen, Kosten, Tokens, Tool-Budgets und Harness-Fehler speichert, anstatt eine Evaluierung auf eine heroische Zahl zu reduzieren. Ein Benchmark, der nicht geprüft werden kann, ist nur ein weiteres Modell, das eine selbstbewusste Behauptung aufstellt.

Evidenz ist das Produkt

Die Neuheit liegt nicht darin, dass ein LLM Routen auflisten, eine HTTP-Anfrage senden oder einen Patch vorschlagen kann. Wir wissen, dass es das kann. Der schwierige Teil ist sicherzustellen, dass die Untersuchung überprüfbar bleibt, wenn sie den Kontextfenster des Modells verlässt.

ExploitHunter behält persistenten Projektspeicher und Thread-Verlauf, aber das dauerhafte Protokoll ist die Evidenzpipeline: was versucht wurde, unter welcher Genehmigung, gegen welches autorisierte Ziel, und was zurückkam. Erkenntnisse können dann in die Verfolgung von Behebungen, Variantenanalyse, Angriffspfadarbeit und einen Bericht mit Zitaten einfließen, statt in einen selbstbewussten Prose-Klumpen.

Dieses Design hat einen egoistischen Vorteil: Es macht das System leichter zu debuggen. Wenn der Agent etwas übersieht, Werkzeuge übermäßig nutzt, eine Schlussfolgerung erfindet oder ein Artefakt nicht speichert, ist das Problem sichtbar. Wir können das Produkt reparieren, anstatt mit einem Screenshot einer Chat-Blase zu argumentieren.

Lokal ausführen. Verantwortungsvoll nutzen.

ExploitHunter ist MIT-lizenziert, Open Source und für Arbeiten konzipiert, für die Sie autorisiert sind. Das Repository enthält ein lokales gehärtetes Juice-Shop-Ziel und Multi-Service-Netzwerklabore zum Testen des Workflows, ohne einen Agenten auf etwas zu richten, das Sie nicht besitzen.

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

Öffnen Sie dann http://localhost:3210.

Beginnen Sie mit einem Ziel, das Sie besitzen oder für das Sie ausdrückliche Testgenehmigung haben. Notieren Sie den Umfang. Lassen Sie den Agenten einen Plan erstellen. Genehmigen Sie die Aktion, die Sie tatsächlich beabsichtigen. Heben Sie die Belege auf.

Das ist die langweilige Version von agentischer Sicherheit.

Es ist auch die Version, die ich auf meiner Seite haben möchte, wenn der interessante Teil beginnt.

Was kommt als Nächstes

Die nächste Aufgabe ist keine große Behauptung über autonomes Hacken. Es geht darum, den Forschungsloop vertrauenswürdiger zu machen: bessere Wiederholbarkeit von Berichten, strengere Nachweisvalidierung, mehr Abdeckung lokaler Modelle, klarere Genehmigungssichtbarkeit und schnellere Wege von einem verifizierten Befund zu einem Patch, den ein Mensch übernehmen möchte.

Sicherheitsagenten brauchen nicht mehr Erlaubnis zu improvisieren.

Sie brauchen bessere Einschränkungen, bessere Belege und eine Möglichkeit, nützlich zu sein, bevor die Rechnung eintrifft.

Evaluations-Snapshot verifiziert am 17. Juli 2026. Die obigen Metriken stammen aus den im Repository dokumentierten Hard Juice Shop, Docker-Netzwerk, lokalem Tool-Verhalten und LM Studio Preflight-Läufen, mit den entsprechenden Langfuse-Traces im Nur-Lese-Zugriff geprüft. Sie beschreiben diese Evaluationsbedingungen, keine Garantie für die Leistung auf jedem Ziel.