03. Juni 2026·3 min Lesezeit·vu7 Team

Warum Mythos für uns keine Rolle spielt

researchbenchmarkmodels

Anthropic hat vor kurzem mit riesigen amerikanischen Firmen wie Mozilla zusammengearbeitet und ihr Frontier-Modell Claude Mythos auf den Firefox-Quellcode losgelassen. Das Ergebnis waren über 271 bestätigte Schwachstellen; der Hype um das Modell ist real und es gibt Daten die das bestätigen.

context-vs-model

Aber es gibt eine wichtigere Perspektive die oft übersehen wird: Diese Ergebnisse wurden mit einem erfahrenen Operator im Loop erzielt. Ein Researcher, der weiß, wo er suchen muss, wie er den Agenten lenkt, wann er eingreift. Diese Beobachtung beschränkt sich nicht auf Mythos. Auch viele der aktuell erfolgreichsten Agent-Workflows basieren auf einem erfahrenen Security-Researcher, der Ziele auswählt, Hypothesen formuliert und den Agenten in die richtige Richtung lenkt. Die Ergebnisse sind beeindruckend, zeigen aber vor allem, wie produktiv ein guter Researcher mit Frontier-Modellen werden kann.

Aber das sind nicht die Bedingungen, unter denen vu7 arbeitet.

Kein Mensch am Steuer

vu7 hat keinen menschlichen Operator. Kein Researcher, der das Modell leitet mit: „Schau dir diese Funktion noch mal genauer an." Kein Senior Engineer, der den Kontext kennt. Der Agent von vu7 läuft vollautomatisch — von der Code-Analyse bis zum Finding.

Ohne diesen Loop skalieren große Modelle brutal schlecht. Schon ein mittelgroßes Repository wie javaspringvulny kostet in einem vollständigen Frontier-Scan schnell mehrere Hundert Euro. Bei einer realen Codebase oder einem durchschnittlichen SaaS-Produkt reden wir schnell von fünfstelligen Beträgen — pro Scan. Das ist kein Produktionsmodell.

Was die Benchmarks zeigen

Wir haben unsere Pipeline gegen javaspringvulny getestet, ein Spring-Boot-Projekt mit Schwachstellen, welches in der Security-Community als Standard-Benchmark gilt. Das Ergebnis spricht für sich: für den Preis eines einzigen Claude Opus 4.7-Scans kann vu7 29 Mal scannen. Und mehrfache Läufe kleinerer Modelle erreichen eine bessere Findings-Rate wie ein einzelner teurer Lauf.

Ein manuell geführter Frontier-Scan findet nur einen Teil der Oberfläche; SQL Injection hier, Session Fixation dort. Typische High-Hanging-Fruit-Findings, die jedes Tool mit ausreichend Token-Budget findet. Was fehlt, sind die Findings, die Kontext brauchen: Tenant-Isolation-Probleme, Type-Confusion-Bugs, die sich in der Parsing-Logik verstecken oder der hardcoded Secret Key, der erst im Zusammenspiel mit dem JWT-Flow zum kritischen Finding wird.

Kontext schlägt Modellgröße

Der Type-Confusion-Bug ist ein gutes Beispiel dafür, warum Modellgröße oft das falsche Framing ist. Um diese Zeile als Vulnerability zu erkennen, muss das Modell wissen, wie die JDK-Methode intern funktioniert und den Aufruf in seinen Datenfluss-Kontext einbetten.

context-vs-model

In den erfolgreichen Fällen hatte unsere Context Engine die relevante API-Dokumentation und den Dataflow eingebettet. Im Fehlerfall fehlte sie. Das bedeutet, dass der richtige Kontext wichtiger als das neueste Modell ist.

Genau hier liegt die eigentliche Arbeit — und der eigentliche Mehrwert von vu7.

Was das für vu7 bedeutet

Wir bauen keine Lösung für Mozilla oder Google. Wir bauen eine Lösung für die 99 % der Anwendungen, die keine JIT-Compiler sind. Für SaaS-Produkte, APIs, Webapps, den normalen Stack, der täglich deployt wird.

Unser Ansatz: Pre-Processing, Kontextanreicherung und strukturierte Präsentation des Codes - so dass auch ein kleineres Modell die Schwachstellen findet, die ein Frontier-Modell nur mit Human-in-the-Loop finden würde. Und das Ganze zu einem Preis, der für kontinuierliche Scans auf jedem PR tragbar ist.

Frontier-Modelle sind beeindruckend. Aber für unseren Use Case sind sie schlicht nicht das richtige Werkzeug und die Benchmarks geben uns recht.