Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

Die Studie stellt FSTab vor, einen Black-Box-Ansatz zur Vorhersage und Quantifizierung wiederkehrender Sicherheitslücken in von LLMs generierter Software, der auf Basis beobachtbarer Frontend-Features und des verwendeten Modells bis zu 94 % Angriffserfolge über verschiedene Anwendungsbereiche hinweg erzielt.

Das Wesentliche

Stell dir vor, du hast einen sehr talentierten, aber etwas skurrilen Koch namens „Künstliche Intelligenz" (KI). Dieser Koch kann unglaublich schnell Rezepte für komplexe Gerichte (Software-Code) schreiben. Er ist so schnell, dass fast jede moderne Küche ihn nutzt, um neue Menüs zu kreieren.

Das Problem ist: Dieser Koch hat eine seltsame Angewohnheit. Wenn er ein bestimmtes Gericht zubereitet – sagen wir, einen „Schokoladenkuchen" (eine Funktion wie „Benutzer anmelden") – dann macht er immer genau denselben Fehler. Vielleicht vergisst er jedes Mal, das Backofentürschloss zu prüfen, oder er benutzt immer dasselbe, kaputte Messer.

Die Forscher dieses Papers haben herausgefunden, dass man diesen Fehler vorhersagen kann, ohne jemals in die Küche zu schauen.

Hier ist die Erklärung der Studie in einfachen Worten:

1. Das Problem: Der „Koch" macht immer denselben Fehler

Wenn KI-Modelle Code schreiben, nutzen sie oft immer wieder dieselben Baupläne (Templates). Das ist wie ein Koch, der bei jedem Rezept für „Pizza" versehentlich Salz statt Zucker in den Teig gibt.

• Das Risiko: Wenn ein Angreifer weiß, dass der Koch (das KI-Modell) immer Salz in den Teig gibt, muss er nicht jedes einzelne Restaurant überprüfen. Er weiß einfach: „Wenn ich eine Pizza esse, die von diesem Koch gemacht wurde, ist sie ungenießbar."
• Die Gefahr: Diese Fehler sind oft Sicherheitslücken (z. B. Hacker können sich leicht anmelden, weil das Schloss fehlt).

2. Die Lösung: Die „Fehler-Karte" (FSTab)

Die Forscher haben eine neue Methode namens FSTab (Feature–Security Table) entwickelt. Stell dir das wie eine Detektiv-Mappe vor.

• Wie funktioniert es?
  Der Detektiv (der Angreifer) geht nicht in den Keller des Gebäudes (den Backend-Code), wo die eigentliche Gefahr lauert. Stattdessen schaut er sich nur das Vorderzimmer (die Benutzeroberfläche) an.

  • Sieht er einen „Passwort-Login"? -> Die Karte sagt: „Achtung! Der Koch benutzt hier immer ein kaputtes Schloss."
  • Sieht er einen „Datei-Upload"? -> Die Karte sagt: „Achtung! Hier vergisst der Koch immer den Schutzzauber."

• Der Clou: Der Detektiv braucht keinen Schlüssel zum Keller. Er kennt nur den Namen des Kochs (z. B. „GPT-5.2" oder „Claude") und sieht, was der Benutzer tun kann. Basierend darauf sagt die Karte voraus, wo im Keller die Fallen liegen.

3. Die Entdeckung: Der „Fingerabdruck"

Die Studie hat gezeigt, dass jeder KI-Koch einen einzigartigen Sicherheits-Fingerabdruck hat.

• Ein Koch (Modell A) macht bei „Login" immer einen bestimmten Fehler.
• Ein anderer Koch (Modell B) macht bei „Login" einen ganz anderen Fehler, aber dafür bei „Zahlung" immer denselben.

Das ist wie bei einem Maler: Wenn du siehst, dass ein Maler immer die Fenster in einem bestimmten, unsicheren Stil malt, weißt du sofort, dass er auch die Türen auf die gleiche unsichere Weise gebaut hat, auch wenn du die Türen noch nicht gesehen hast.

4. Was passiert, wenn man den Koch ändert?

Die Forscher haben getestet, ob diese Fehler nur in einem bestimmten Bereich (z. B. nur bei Online-Shops) auftreten oder überall.

• Ergebnis: Die Fehler sind universell. Wenn der Koch einen Fehler beim „Login" in einem Blog macht, macht er denselben Fehler beim „Login" in einem Finanz-System.
• Die „Universalitäts-Lücke": Das ist beunruhigend. Es bedeutet, dass man einen Angreifer nicht davon abhalten kann, indem man das Thema wechselt. Wenn man weiß, wie der Koch tickt, kann man ihn überall hacken, egal ob er gerade ein Rezept für eine Pizza oder einen Flugplan schreibt.

5. Warum ist das wichtig?

Bisher haben Sicherheits-Experten gedacht: „Wir müssen jeden einzelnen Code-Block prüfen, um Fehler zu finden." Das ist wie das Überprüfen jedes einzelnen Ziegelsteins in einer Stadt.

Diese Studie sagt: „Nein, wir müssen nur wissen, wer die Stadt gebaut hat und welche Funktionen sie hat."

• Für Hacker: Es ist ein einfacher Weg, um Schwachstellen zu finden, ohne den Code zu sehen (ein „Black-Box"-Angriff).
• Für Sicherheitsexperten: Es ist ein Warnsignal. Wir müssen die KI-Modelle selbst trainieren, damit sie nicht immer dieselben unsicheren Muster wiederholen. Wir müssen den Koch beibringen, dass er beim Backen von „Schokoladenkuchen" endlich das Schloss prüft.

Zusammenfassung in einem Satz

Die Forscher haben entdeckt, dass KI-generierte Software wie ein Maschinengewehr ist, das immer in die gleiche Richtung schießt: Wenn du weißt, welches Modell den Code geschrieben hat und welche Funktionen es hat, kannst du vorhersagen, wo die Sicherheitslücken liegen, ohne jemals den Code selbst zu sehen.

Technische Zusammenfassung

Titel: Extrahierung wiederkehrender Sicherheitslücken aus Black-Box-LLM-generierter Software

1. Problemstellung

Große Sprachmodelle (LLMs) werden zunehmend für die automatische Code-Generierung eingesetzt. Obwohl sie die Entwicklung beschleunigen, neigen sie dazu, wiederkehrende Vorlagen und Muster zu verwenden, die zu vorhersehbaren Sicherheitslücken führen.

• Das Kernproblem: Herkömmliche Sicherheitsansätze (wie statische Analysen) betrachten generierten Code oft isoliert. Sie erkennen zwar einzelne Fehler, modellieren aber nicht die querschnittlichen Regularitäten, die durch die zugrunde liegende Generierungslogik eines spezifischen LLMs entstehen.
• Die Gefahr: Da LLMs probabilistisch arbeiten, wiederholen sie bei ähnlichen Anforderungen (z. B. „Benutzeranmeldung" oder „Datei-Upload") oft dieselben unsicheren Implementierungsmuster. Dies schafft eine vorhersehbare Angriffsfläche, die es einem Angreifer ermöglicht, versteckte Backend-Schwachstellen allein basierend auf sichtbaren Frontend-Funktionen vorherzusagen, ohne Zugriff auf den Quellcode zu haben.

2. Methodik: Feature–Security Table (FSTab)

Die Autoren stellen FSTab vor, ein Framework, das zwei Hauptkomponenten umfasst: einen Black-Box-Angriff und ein bewertungsbasiertes Evaluierungsmodell.

A. Der Black-Box-Angriff (FSTab-Attacke)
Das Ziel ist es, Backend-Schwachstellen ($B$) allein aus beobachtbaren Frontend-Funktionen ($F$) und der Identität des Quell-LLM ($M$) zu inferieren.

1. Konstruktion der Tabelle:
   • Es werden große Korpora von Anwendungen generiert, die vom Ziel-LLM erstellt wurden.
   • Diese werden mit statischen Analyse-Tools (CodeQL, Semgrep) auf Schwachstellen und mit Feature-Scannern auf Frontend-Funktionen geprüft.
   • Es entsteht eine Lookup-Tabelle, die Frontend-Features (z. B. „Passwort-Login") mit Backend-Sicherheitsregeln (CWEs) verknüpft.
2. Statistische Modellierung:
   • Anstatt rohe Häufigkeiten zu nutzen, wird die Pointwise Mutual Information (PMI) verwendet, um die Assoziation zwischen einem Feature $f$ und einer Schwachstelle $r$ zu berechnen:
     $$S_{PMI}(f, r) = \log \left( \frac{\hat{P}(r|f)}{\hat{P}(r)} \right)$$
   • Ein Diversitäts-Algorithmus verhindert, dass generische Regeln für alle Features priorisiert werden, und sorgt für eine spezifische Abbildung.
3. Angriffsablauf:
   • Ein Angreifer identifiziert Frontend-Features (z. B. über UI-Interaktion).
   • Unter Nutzung der bekannten Modell-ID wird die entsprechende FSTab abgefragt.
   • Die Tabelle liefert eine priorisierte Liste der wahrscheinlichsten Backend-Schwachstellen.

B. Evaluierungs-Framework
Um die Persistenz von Schwachstellen zu quantifizieren, werden vier Metriken definiert:

1. FVR (Feature Vulnerability Recurrence): Wie oft tritt dieselbe Schwachstelle bei einem bestimmten Frontend-Feature über verschiedene Programme hinweg auf?
2. RVP (Rephrasing Vulnerability Persistence): Bleibt die Schwachstelle bestehen, wenn die Prompt-Anfrage semantisch gleich, aber syntaktisch anders formuliert wird?
3. DVR (Domain Vulnerability Recurrence): Wie oft wiederholen sich Schwachstellen innerhalb desselben Anwendungsbereichs (z. B. E-Commerce)?
4. CDT (Cross-Domain Transfer): Kann eine aus einem Bereich (z. B. Blogs) gelernte FSTab erfolgreich auf einen anderen Bereich (z. B. Dashboards) angewendet werden?

3. Schlüsselergebnisse

Die Studie wurde an sechs State-of-the-Art-Code-LLMs (u. a. GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro, Grok) über fünf Anwendungsbereiche (E-Commerce, Interne Tools, Social Media, etc.) durchgeführt.

• Hohe Angriffserfolgsrate (ASR): Der Black-Box-Angriff ist extrem effektiv. Auf dem Modell Claude-4.5 Opus wurde eine ASR von bis zu 94% und eine Vulnerability Coverage von 93% erreicht, selbst wenn das Zielfeld im Trainingsdatensatz ausgeschlossen war.
• Cross-Domain Transfer (CDT): Schwachstellenmuster sind oft domänenunabhängig. Die CDT-Werte waren häufig höher als die DVR-Werte (ein Phänomen, das als „Universality Gap" bezeichnet wird). Das bedeutet, dass Angreifer Schwachstellenmuster aus einem Bereich lernen und erfolgreich auf völlig andere Anwendungen anwenden können.
• Modellspezifische Fingerabdrücke: Jedes Modell entwickelt ein einzigartiges „Sicherheitsprofil". Beispielsweise zeigte Composer eine hohe Persistenz (RVP $\approx$ 50%), während Grok sensitiver auf Prompt-Änderungen reagierte, aber dennoch starke architektonische Verzerrungen aufwies.
• Vorhersehbarkeit: Bestimmte Features (z. B. „Neues Konto registrieren") führten bei mehreren Modellen zu einer 100%igen Wiederholungsrate spezifischer Schwachstellen (z. B. SQL-Injection oder XSS).

4. Hauptbeiträge

1. Universaler Black-Box-Angriff: Einführung von FSTab als erster Methode, die es ermöglicht, Backend-Schwachstellen in LLM-generierter Software ohne Quellcode-Zugriff vorherzusagen.
2. Modell-zentrisches Evaluierungs-Framework: Bereitstellung von Metriken (FVR, RVP, DVR, CDT), um die Persistenz von Schwachstellenmustern über Domänen und Prompt-Variationen hinweg zu messen.
3. Empirische Charakterisierung: Umfassende Analyse, die zeigt, dass Sicherheitsrisiken in LLMs nicht zufällig sind, sondern durch stabile, modellinterne Bias-Strukturen verursacht werden, die sich über verschiedene Kontexte hinweg wiederholen.

5. Bedeutung und Implikationen

• Neue Angriffsfläche: Die Arbeit enthüllt eine bisher wenig untersuchte Angriffsfläche: Die inhärente Vorhersehbarkeit von Sicherheitslücken basierend auf der Modell-ID und sichtbaren Funktionen.
• Sicherheitsrisiko: Da LLMs oft in Produktionsumgebungen eingesetzt werden, ohne dass der Quellcode vollständig geprüft wird, ermöglicht FSTab Angreifern, gezielte Angriffe zu planen, lange bevor der Code deployed oder manuell auditiert wird.
• Verteidigungsstrategien: Die Ergebnisse unterstreichen die Notwendigkeit von:
  • Modell-zentrischen Audits: Sicherheitsbewertungen sollten nicht nur den generierten Code, sondern die Persistenz von Mustern im Modell selbst betrachten.
  • Feature-basierten Regressionstests: Hochrisiko-Features sollten systematisch auf bekannte, wiederkehrende Muster getestet werden.
  • Reduzierung von Template-Rigidität: Modelle sollten so trainiert oder fine-getuned werden, dass sie weniger starre, unsichere Vorlagen für kritische Funktionen verwenden.

Fazit: Das Paper demonstriert, dass LLM-generierter Code keine zufälligen Fehler produziert, sondern systematische, wiederkehrende Schwachstellenmuster aufweist, die als „Sicherheitsfingerabdrücke" des Modells genutzt werden können, um Black-Box-Angriffe mit hoher Präzision durchzuführen.