TOSSS: a CVE-based Software Security Benchmark for Large Language Models

Das Paper stellt TOSSS vor, ein auf CVE-Daten basierendes Benchmark-System zur Bewertung der Fähigkeit von Large Language Models, sichere von anfälligen Code-Snippets in C/C++ und Java zu unterscheiden, wobei die getesteten Modelle Sicherheitswerte zwischen 0,48 und 0,89 erreichten.

Das Wesentliche

Hier ist eine einfache Erklärung der Studie „TOSSS" auf Deutsch, die komplexe Konzepte mit alltäglichen Vergleichen verknüpft.

🛡️ TOSSS: Der Sicherheits-Test für KI-Codierer

Stellen Sie sich vor, Sie haben einen sehr klugen, aber manchmal etwas naiven Koch-Assistenten (eine KI, genauer gesagt ein „Large Language Model" oder LLM). Dieser Koch kann Rezepte (Code) für Sie schreiben. Aber ist er auch ein guter Sicherheitsinspektor? Kann er erkennen, wenn ein Rezept eine tödliche Falle enthält (z. B. ein offenes Gasventil), oder schreibt er einfach nur schnell das Rezept auf, ohne auf die Gefahren zu achten?

Bisher gab es Tests, bei denen man den Koch bat, ein ganz neues Gericht zu kochen, und dann geprüft hat, ob das Essen giftig war. Das Problem dabei: Es war schwer zu sagen, ob der Koch wirklich wusste, dass es giftig war, oder ob er einfach nur Glück hatte. Außerdem waren diese Tests oft starr und ließen sich nicht leicht auf neue Arten von Gift (neue Sicherheitslücken) erweitern.

Die Forscher haben eine neue Idee entwickelt: TOSSS.

🎯 Das Konzept: Das „A oder B"-Spiel

Statt den Koch zu bitten, ein neues Gericht zu erfinden, sagen sie ihm:

„Hier sind zwei Versionen desselben Rezepts. Version A und Version B. Eine ist sicher, die andere hat einen versteckten Defekt. Welche wählst du?"

Das ist wie ein Sicherheits-Quiz.

• Die Aufgabe: Die KI muss zwischen einem sicheren Code-Stück und einem unsicheren Code-Stück wählen.
• Die Bewertung: Wenn die KI immer die sichere Version wählt, bekommt sie eine 1 (perfekt). Wählt sie zufällig, bekommt sie eine 0,5. Wählt sie oft die unsichere Version, bekommt sie eine 0 (schlecht).

🕵️‍♂️ Woher kommen die Fragen? (Der Schatz der CVEs)

Früher mussten Forscher manuell solche „A oder B"-Fragen erfinden. Das war mühsam und langsam.
TOSSS nutzt stattdessen eine riesige Datenbank namens CVE (eine Art „Polizeiliches Register für Software-Sicherheitslücken").

Stellen Sie sich vor, ein Programmierer hat einen Fehler in seiner Software gefunden und ihn später repariert. TOSSS schaut sich genau diese beiden Versionen an:

1. Die alte Version mit dem Fehler (die „vergiftete" Version).
2. Die neue Version mit dem Reparatur (die „sichere" Version).

Das System holt sich diese Paare automatisch aus der Datenbank. Das ist wie ein automatischer Roboter, der ständig neue Sicherheitsfragen aus der echten Welt sammelt. Sobald ein neuer Fehler entdeckt wird, kann das System ihn sofort in den Test einbauen. Das macht den Test zukunftssicher.

🧪 Was haben sie herausgefunden?

Die Forscher haben 14 verschiedene KIs (von bekannten Firmen wie OpenAI, Google, Anthropic etc.) auf diesen Test angesetzt. Hier sind die wichtigsten Erkenntnisse, einfach erklärt:

1. Nicht alle KIs sind gleich gut:
   Die Ergebnisse reichten von „fast zufällig ratend" (ca. 0,48 Punkte) bis „sehr sicher" (ca. 0,89 Punkte). Nicht jede KI ist automatisch ein Sicherheits-Experte.

2. Der „Hinweis"-Effekt:

   • Ohne Hinweis: Die KIs mussten raten, welche Version besser ist, ohne zu wissen, dass es um Sicherheit geht. Viele haben es trotzdem gut gemacht.
   • Mit Hinweis: Wenn man den KIs explizit sagte: „Wähle die sicherste Version!", wurden sie fast alle besser.
   • Die Ausnahme: Eine spezielle „Code-KI" (Codestral) wurde sogar schlechter, wenn man sie auf Sicherheit hinwies. Vielleicht war sie so darauf trainiert, nur funktionierenden Code zu schreiben, dass der Sicherheits-Hinweis sie verwirrt hat.

3. Spezialisten sind nicht immer die Besten:
   Man könnte denken, dass KIs, die speziell für Programmieren gemacht wurden, die besten Sicherheitsentscheidungen treffen. Aber das war nicht immer der Fall. Manchmal waren die allgemeinen KIs besser darin, die unsichere Version zu erkennen.

💡 Warum ist das wichtig?

Stellen Sie sich vor, Sie bauen ein Haus.

• Der alte Test (Code-Generierung): Der Architekt entwirft ein Haus. Sie prüfen am Ende, ob es einstürzt. Das ist schwer zu bewerten.
• Der neue Test (TOSSS): Sie zeigen dem Architekten zwei Baupläne und fragen: „Welcher Plan ist sicherer?" Das ist viel einfacher zu messen und zeigt sofort, ob der Architekt ein Gefühl für Sicherheit hat.

Das Fazit der Studie:
KI-Assistenten können heute schon recht gut zwischen sicherem und unsicherem Code unterscheiden, aber sie brauchen oft einen kleinen „Stupser" (einen Hinweis im Prompt), um ihr volles Potenzial zu entfalten. TOSSS ist wie ein neuer, flexibler Sicherheits-Test, der sich ständig aktualisiert, sobald neue Gefahren entdeckt werden. Er hilft Entwicklern und Firmen zu verstehen, welcher KI-Assistent wirklich vertrauenswürdig ist, wenn es um die Sicherheit von Software geht.

Die Forscher haben den Test sogar kostenlos veröffentlicht, damit jeder ihn nutzen kann, um seine eigenen KIs zu prüfen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „TOSSS: a CVE-based Software Security Benchmark for Large Language Models" auf Deutsch:

1. Problemstellung

Große Sprachmodelle (LLMs) werden zunehmend in Softwareentwicklungsworkflows integriert, um Aufgaben wie Code-Generierung und -Vervollständigung zu übernehmen. Studien zeigen jedoch, dass von LLMs generierter Code häufig Sicherheitslücken enthält (z. B. 40 % bei GitHub Copilot).

Bestehende Sicherheits-Benchmarks für LLMs weisen jedoch erhebliche Mängel auf:

• Eingeschränkte Erweiterbarkeit: Sie basieren oft auf festen Aufgabenmengen und statischen Analyse-Tools (wie CodeQL). Neue, gerade entdeckte Schwachstellen oder neue Programmiersprachen können nur schwer integriert werden, da die Abdeckung durch die Fähigkeiten der Analysetools begrenzt ist.
• Fehlende Ground-Truth-Vergleiche: Bei Code-Generierungsaufgaben ist es schwierig, den Output mit einer vordefinierten Referenzimplementierung zu vergleichen. Die Bewertung erfolgt oft indirekt über externe Tools, was zu Bias und Skalierungsproblemen führt.
• Manuelle Aufwände: Viele Ansätze erfordern manuelle Validierung oder die Erstellung von Testfällen, was nicht skalierbar ist.

Es besteht daher ein dringender Bedarf an einem skalierbaren, erweiterbaren Benchmark, der die Fähigkeit von LLMs zur Erkennung und Auswahl sicherer Code-Implementierungen objektiv misst.

2. Methodik: TOSSS (Two-Option Secure Snippet Selection)

Das Paper stellt TOSSS vor, einen neuen Benchmark, der die Evaluierung von Code-Generierung in eine Code-Auswahl-Aufgabe umwandelt.

• Kernkonzept: Dem Modell werden zwei Versionen derselben Funktion präsentiert: eine verwundbare (vulnerable) und eine sichere Version. Das Modell muss sich für eine der beiden Optionen (A oder B) entscheiden.
• Datengrundlage (CVE-Mining): Anstatt manuelle Testfälle zu erstellen, nutzt TOSSS die CVE-Datenbank (Common Vulnerabilities and Exposures). Es baut auf dem bestehenden Projekt MegaVul auf, das eine automatisierte Pipeline zur Extraktion von Code-Versionen vor und nach einem Sicherheitsfix bietet.
  • Dies ermöglicht die automatische Generierung von Testpaaren für C/C++ und Java.
  • Neue CVEs können automatisch in den Benchmark integriert werden, was die Erweiterbarkeit sicherstellt.
• Bewertungsmetrik: Der Sicherheits-Score ist definiert als der Anteil der korrekt ausgewählten sicheren Snippets.
  • Score 1,0: Das Modell wählt immer die sichere Version.
  • Score 0,5: Zufällige Auswahl.
  • Score < 0,5: Das Modell bevorzugt verwundbaren Code.
• Prompt-Varianten:
  1. Hintless (ohne Hinweis): Das Modell wird nicht explizit darauf hingewiesen, dass es um Sicherheit geht (allgemeine Auswahl).
  2. With Hint: Das Modell wird explizit angewiesen, die „sicherste Implementierung" auszuwählen.

3. Wichtige Beiträge

1. Neuer Benchmark-Ansatz: TOSSS ist der erste Benchmark, der auf der Auswahl zwischen zwei Code-Varianten (Ground-Truth-Paare) statt auf der Generierung von Code basiert. Dies eliminiert Probleme mit Formatierungsfehlern und ermöglicht eine direkte Vergleichbarkeit.
2. Automatisierte Erweiterbarkeit: Durch die Kopplung mit der CVE-Datenbank und MegaVul kann der Benchmark kontinuierlich neue Schwachstellen und Sprachen integrieren, ohne manuelle Eingriffe.
3. Interpretierbare Metrik: Der Score hat eine klare probabilistische Bedeutung (Wahrscheinlichkeit, die sichere Option zu wählen), im Gegensatz zu komplexeren Metriken wie pass@k.
4. Open-Source-Verfügbarkeit: Der gesamte Code und die Datenpipeline wurden veröffentlicht, um Reproduzierbarkeit und Adoption zu fördern.

4. Experimentelle Ergebnisse

Die Autoren evaluierten 14 Modelle (Open-Source und Closed-Source, z. B. GPT-5, Claude, LLaMA, Mistral) an 500 C/C++- und 500 Java-Funktionen.

• Gesamtscores: Die Scores reichten von 0,48 bis 0,89.
  • Die besten Modelle (z. B. GLM-5, GPT-5.4, Claude Opus 4.6) erreichten Scores > 0,85.
  • Ein Modell (Mistral Large 2512) erreichte im „hintless"-Modus einen Score von ~0,48, was kaum besser als zufälliges Raten ist.
• Einfluss von Hinweisen: Die explizite Aufforderung, die sicherste Option zu wählen („Hint"), verbesserte die Scores bei den meisten Modellen leicht (durchschnittlich +0,02 bis +0,03).
  • Schwächere Modelle profitierten stärker von Hinweisen.
  • Überraschendes Ergebnis: Das spezialisierte Codierungsmodell Codestral 2508 verschlechterte seine Performance bei der Sicherheits-Hinweis-Gabe. Dies deutet darauf hin, dass eine Optimierung auf reine Code-Generierung nicht automatisch zu besserer Sicherheitsentscheidung führt und explizite Sicherheitsanweisungen sogar störend wirken können.
• Sprachvergleich: Die Performance war zwischen C/C++ und Java ähnlich, wobei C/C++ leicht besser abschnitt (möglicherweise aufgrund mehrerer Trainingsdaten).
• Modell-Familien: Neuere und größere Versionen innerhalb derselben Familie (z. B. Claude 3.5 vs. 4.6) zeigten konsistent bessere Sicherheitsfähigkeiten.

5. Bedeutung und Fazit

TOSSS bietet einen robusten, skalierbaren und erweiterbaren Weg, um die Sicherheitskompetenz von LLMs zu bewerten. Die Ergebnisse zeigen, dass:

1. Moderne LLMs grundsätzlich in der Lage sind, sichere von unsicheren Code-Implementierungen zu unterscheiden, aber die Leistung stark variiert.
2. Die bloße Spezialisierung auf Codierung (Coding-Models) keine Garantie für hohe Sicherheitsstandards ist.
3. Explizite Sicherheitsanweisungen im Prompt die Leistung der meisten Modelle verbessern können.

Der Benchmark dient als komplementäres Werkzeug zu bestehenden Generierungs-Benchmarks. Da die Fähigkeit, die sichere Option zu erkennen, eine Grundvoraussetzung für das Generieren sicheren Codes ist, liefert TOSSS ein effizientes Maß für die inhärente Sicherheitsintelligenz von LLMs. Die Arbeit unterstreicht die Notwendigkeit, Sicherheitsaspekte systematisch in die Evaluierung und das Training von KI-Modellen für die Softwareentwicklung zu integrieren.