💻 computer science

Guiding Symbolic Execution with Static Analysis and LLMs for Vulnerability Discovery

Die Studie stellt SAILOR vor, ein System, das statische Analyse und Large Language Models kombiniert, um die Erstellung von Symbolic-Execution-Harnesses zu automatisieren und dadurch in großem Maßstab neue Speicher-Sicherheitslücken in C/C++-Projekten zu entdecken, die mit reinen LLM-Ansätzen unentdeckt blieben.

Ursprüngliche Autoren: Md Shafiuzzaman, Achintya Desai, Wenbo Guo, Tevfik Bultan

Veröffentlicht 2026-04-09

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Md Shafiuzzaman, Achintya Desai, Wenbo Guo, Tevfik Bultan

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Sicherheitsinspektor in einer riesigen, verlassenen Fabrik (das ist der riesige Computercode eines Programms). Ihre Aufgabe ist es, versteckte Fallen zu finden, die dazu führen könnten, dass die Fabrik einstürzt (Sicherheitslücken).

Das Problem? Die Fabrik ist so groß, dass Sie sie nicht einfach von Hand durchsuchen können. Und wenn Sie einen Roboter (ein automatisches Werkzeug) schicken, stolpert dieser oft über Dinge, die gar keine Fallen sind, oder findet die echten Fallen nicht, weil er nicht weiß, wo er anfangen soll.

Die Forscher aus diesem Papier haben eine neue Methode namens Sailor entwickelt. Man kann sich Sailor wie ein drei-Phasen-Team aus Spezialisten vorstellen, das zusammenarbeitet, um diese Fallen zu finden.

Hier ist die einfache Erklärung, wie Sailor funktioniert:

Phase 1: Der Detektiv (Statische Analyse)

Stellen Sie sich einen sehr schnellen, aber etwas oberflächlichen Detektiv vor. Er läuft durch die Fabrik und schaut sich nur die Wände an. Er sucht nach bekannten Mustern für Gefahren, wie zum Beispiel: "Hey, hier wurde ein Loch in die Wand geschlagen, ohne zu prüfen, ob dahinter jemand steht!"

Was er macht: Er scannt den riesigen Code und markiert tausende von Orten, die verdächtig aussehen.
Das Problem: Er ist sehr vorsichtig und meldet oft Dinge, die gar keine echten Probleme sind (falsche Alarme). Er weiß aber nicht genau, wie man die Fabrik so manipuliert, dass die Falle zuschnappt. Er sagt nur: "Hier könnte was sein."

Phase 2: Der Architekt und der Baumeister (LLM & Symbolische Ausführung)

Jetzt kommt das Genie des Teams ins Spiel: Ein künstlicher Intelligenz-Architekt (LLM). Dieser Architekt ist extrem kreativ und gut im Verstehen von komplexen Plänen, aber er braucht eine klare Aufgabe.

Die Aufgabe: Der Architekt bekommt die Liste des Detektivs aus Phase 1. Für jeden verdächtigen Ort muss er nun einen perfekten Testplan (einen "Harnisch") bauen.
Was ist ein Harnisch? Stellen Sie sich vor, um eine Falle in der Fabrik auszulösen, müssen Sie genau die richtige Tür öffnen, genau den richtigen Hebel ziehen und genau den richtigen Gegenstand werfen. Ein normales Werkzeug weiß nicht, wie man das macht. Der Architekt schreibt das Skript dafür.
Der iterative Prozess (Das Wichtigste!): Der Architekt ist nicht perfekt beim ersten Versuch.
1. Er baut den Testplan.
2. Ein Roboter-Tester (Symbolische Ausführung) führt den Plan aus.
3. Wenn der Plan scheitert (z. B. weil eine Tür nicht aufgeht oder der Roboter gegen eine Wand läuft), gibt der Tester dem Architekten Feedback: "Hey, du hast vergessen, den Schlüssel zu drehen!"
4. Der Architekt korrigiert den Plan und versucht es erneut.
5. Dieser Kreislauf läuft so lange, bis der Roboter genau die richtige Kombination findet, um die Falle auszulösen.

Phase 3: Der Beweis (Konkrete Überprüfung)

Angenommen, der Roboter hat eine Falle ausgelöst und einen Beweis (einen "Zeugen") gefunden. Aber ist das echt? Oder hat der Architekt nur einen Plan gebaut, der in der Theorie funktioniert, aber in der echten Welt nicht?

Der Test: Jetzt nehmen wir den Beweis und führen ihn in der echten, unveränderten Fabrik aus. Wir nutzen ein Werkzeug, das sofort schreit, wenn etwas kaputtgeht (AddressSanitizer).
Das Ergebnis: Wenn die echte Fabrik wirklich abstürzt, ist die Lücke bestätigt. Wenn nicht, war es nur ein falscher Alarm.

Warum ist das so erfolgreich?

Die Forscher haben Sailor an 10 riesigen Software-Projekten getestet (zusammen so groß wie 6,8 Millionen Zeilen Code!).

Das Ergebnis: Sailor hat 379 völlig neue, bisher unbekannte Sicherheitslücken gefunden.
Der Vergleich: Andere Methoden, die nur auf KI setzen (ohne den Detektiv und den Roboter-Tester), haben nur 12 Lücken gefunden. Methoden, die nur auf den Detektiv setzen, finden Tausende von falschen Alarmen.

Die einfache Moral der Geschichte

Früher musste man für jede dieser Fallen einen menschlichen Experten haben, der wochenlang einen Testplan schreibt. Das geht nicht bei Millionen Zeilen Code.

Sailor löst das Problem, indem es die Stärken aller kombiniert:

Der Detektiv findet die Nadel im Heuhaufen.
Der KI-Architekt baut den Schlüssel, um die Nadel zu erreichen.
Der Roboter-Tester probiert den Schlüssel aus und verbessert ihn, bis er passt.
Der echte Test bestätigt, dass es wirklich eine echte Lücke ist.

Es ist wie ein Team, bei dem niemand allein perfekt ist, aber zusammen siegen sie über die Komplexität der modernen Software-Welt.

1. Problemstellung

Die automatische Erkennung von Sicherheitslücken in großen C/C++-Codebasen stellt eine langjährige Herausforderung dar. Bestehende Techniken haben jeweils signifikante Nachteile:

Statische Analyse (SA): Kann Millionen von Zeilen Code scannen und viele Kandidaten identifizieren, leidet aber unter einer extrem hohen Rate an False Positives (falschen Alarmen).
Fuzzing: Testet Programme mit konkreten Eingaben, hat jedoch Schwierigkeiten, tiefe Bibliotheksinternals zu erreichen, die einen präzise aufgebauten Programmzustand erfordern.
Large Language Models (LLMs): Können Code analysieren und Muster erkennen, liefern jedoch keine formalen Korrektheitsgarantien und neigen dazu, entweder nicht-existente Lücken zu melden oder echte Lücken zu übersehen.
Symbolische Ausführung (SE): Bietet hohe Präzision durch das Behandeln von Eingaben als symbolische Werte und die Nutzung von Constraint-Solvern, um konkrete Beweisinputs zu generieren. Der Hauptengpass ist jedoch die Skalierbarkeit: SE erfordert sogenannte „Harnesses" (Testtreiber), die den symbolischen Zustand einrichten, Abhängigkeiten modellieren (Stubs) und Assertions definieren. Das manuelle Schreiben dieser Harnesses erfordert tiefes Expertenwissen und ist für große Codebasen nicht praktikabel.

Das Ziel der Arbeit ist es, diese Lücke zu schließen, indem ein vollautomatisierter Prozess entwickelt wird, der die Skalierbarkeit der statischen Analyse, die Code-Verstehensfähigkeit von LLMs und die Pfadpräzision der symbolischen Ausführung kombiniert.

2. Methodik: Das Sailor-System

Sailor (Static Analysis Informed and LLM-Orchestrated Symbolic Execution) ist eine vollautomatische Pipeline, die in drei Phasen unterteilt ist:

Phase 1: Static Analysis Informed Target Generation (Zielgenerierung)

In dieser Phase wird der Quellcode gescannt, um potenzielle Schwachstellen zu identifizieren und in spezifische Ziele für die symbolische Ausführung zu überführen.

Fact Generation: Ein CodeQL-Datenbank wird erstellt und mit einem Satz von 34 Abfragen (13 Standard, 21 benutzerdefiniert) gescannt, um Speicherfehler (z. B. Pufferüberläufe, Use-After-Free) zu finden.
Fact Enrichment: Für jeden Fund werden kontextuelle Informationen extrahiert: verdächtige Funktionsaufrufe, Zeigervariablen, Längenvariablen und Build-Kontexte (Include-Pfade).
Vulnerability Specification: Aus den Daten wird eine JSON-Spezifikation erstellt, die den Ort der Lücke ( $\ell$ ), eine Beschreibung, die zu testende Funktion (Entry-Point), und eine Assertions-Vorlage (basierend auf dem CWE-Typ) enthält. Diese Spezifikation dient als Eingabe für die LLM-Phase.

Phase 2: LLM-Orchestrated Symbolic Execution (Kernbeitrag)

Dies ist der innovativste Teil, bei dem ein LLM die Konstruktion des Harnesses automatisiert.

Iterativer Synthese-Prozess: Das LLM erhält die Spezifikation aus Phase 1 und generiert iterativ einen Harness (Treiber, Stubs, Assertions).
Feedback-Schleife: Der generierte Code wird kompiliert und von KLEE (dem SE-Engine) ausgeführt.
- Bei Kompilierungsfehlern (z. B. fehlende Typdefinitionen) wird das Fehlerprotokoll an das LLM zurückgesendet, das den Code korrigiert.
- Bei Laufzeitfehlern (z. B. „Site not reached" oder „Bug triggered") erhält das LLM Feedback über den Pfad und passt die Constraints oder Stubs an.
Komponenten des Harnesses:
- Driver: Setzt den symbolischen Zustand auf (z. B. klee_make_symbolic für kritische Variablen, klee_assume für Guard-Bedingungen).
- Stubs: Ersetzen externe Abhängigkeiten, um den Pfad zur Lücke zu isolieren (z. B. Schleifen zu if(1) reduzieren, nicht benötigte Funktionen durch symbolische Stubs ersetzen).
- Assertions: Kodieren die Sicherheitsbedingung (z. B. klee_assert(0) nach der gefährlichen Zeile), damit KLEE einen Fehler meldet, wenn der Pfad erreicht wird.

Phase 3: Concrete Validation (Konkrete Validierung)

Um False Positives zu eliminieren, die durch unrealistische Harnesses des LLM entstehen könnten:

Die symbolischen Witness-Inputs (aus .ktest-Dateien) werden in einen konkreten Replay-Treiber umgewandelt.
Dieser Treiber wird gegen den unveränderten Projektquellcode kompiliert, der mit AddressSanitizer (ASan) instrumentiert ist.
Nur wenn ASan einen Absturz im Originalcode meldet, gilt die Lücke als bestätigt.

3. Wichtige Beiträge

Vollautomatisierte Pipeline: Sailor ist das erste System, das SA, LLMs und SE kombiniert, um Harnesses für symbolische Ausführung in großen Codebasen ohne manuelle Eingriffe zu generieren.
Skalierbarkeit und Präzision: Das System bewältigt Codebasen von bis zu 1,84 Millionen Zeilen (GNU Binutils) und findet Lücken, die für manuelle Analyse zu komplex wären.
End-to-End-Implementierung: Die Kombination aus CodeQL, GPT-5 (als LLM), KLEE und ASan erfordert keine projektspezifische Konfiguration außer einem Build-Skript.
Reproduzierbarkeit: Jeder gefundene Fehler wird durch Pfadconstraints, crashende Inputs, ASan-Stack-Traces und Fuzz-Reproduktions-Samen dokumentiert.

4. Ergebnisse

Das System wurde an 10 Open-Source-C/C++-Projekten (insgesamt 6,8 Millionen Zeilen Code) evaluiert.

Entdeckte Lücken: Sailor entdeckte 379 eindeutige, bisher unbekannte Speicher-Sicherheitslücken (insgesamt 421 bestätigte Abstürze).
Vergleich mit Baselines:
- Der stärkste Baseline-Vergleich (ein autonomes Agent-LLM mit vollem Codezugriff und unbegrenzten Interaktionen, „Claude Code") fand nur 12 Lücken.
- Reine SE-Ansätze mit manuell geschriebenen Harnesses (B1) oder einmalig generierten Harnesses (B2) scheiterten fast vollständig (0 bestätigte Lücken), entweder wegen Kompilierungsfehlern oder weil die Harnesses zu allgemein waren.
- Reine LLM-Ansätze ohne SE zeigten eine extrem hohe False-Positive-Rate (>99%).
Ablationsstudie:
- Ohne statische Analyse (nur LLM-Scan) sank die Anzahl der bestätigten Lücken um den Faktor 12,2 (von 379 auf 31).
- Ohne iterative LLM-Verfeinerung (nur einmalige Generierung) wurden 0 Lücken bestätigt.
- Ohne symbolische Ausführung konnten keine Baselines mehr als 12 Lücken finden.
Kosten: Die Pipeline verarbeitete 87.385 Spezifikationen mit einem durchschnittlichen Token-Verbrauch von 26.000 Tokens pro Spezifikation. Die Kosten pro gefundener Lücke variierten stark (0,9 Mio. Tokens bei mupdf bis 29,2 Mio. bei libxml2), abhängig von der Komplexität der Harness-Generierung, nicht von der Projektgröße.

5. Bedeutung und Fazit

Die Arbeit demonstriert, dass keine einzelne Technik ausreicht, um Sicherheitslücken in großen, komplexen C/C++-Systemen effektiv zu finden.

Statische Analyse liefert die Skalierbarkeit, um die Suchräume einzugrenzen.
LLMs lösen das Problem der Harness-Generierung durch kontextuelles Verständnis und iterative Verfeinerung.
Symbolische Ausführung liefert die mathematische Präzision, um die Existenz eines Angriffsvektors zu beweisen.
Konkrete Validierung stellt die Ground Truth sicher.

Sailor zeigt, dass durch die Orchestrierung dieser Techniken die Skalierbarkeit von Symbolic Execution für reale, industrielle Codebasen erreicht werden kann. Die gefundene Anzahl an Lücken (379) übertrifft alle bisherigen automatisierten Ansätze um ein Vielfaches und unterstreicht das Potenzial hybrider Systeme für die zukünftige Software-Sicherheit. Die Implementierung und die Reproduktionsanweisungen sind öffentlich verfügbar, wobei die Details der neu entdeckten Lücken zurückgehalten werden, bis die verantwortlichen Maintainer informiert wurden.