🤖 AI

An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors

Diese empirische Studie zeigt, dass Large Language Models, insbesondere logikoptimierte wie DeepSeek-R1, bei der Sicherheitsprüfung von Code die fortschrittlichsten statischen Analysewerkzeuge deutlich übertreffen, wobei festgestellt wird, dass Prompt-Engineering-Strategien, Codekomplexität und Dateigröße entscheidende Faktoren für deren Erkennungsgenauigkeit und Antwortqualität sind.

Ursprüngliche Autoren: Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

Veröffentlicht 2026-05-12

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

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 der Redakteur einer riesigen, chaotischen Bibliothek, in der Tausende von Menschen ständig neue Kapitel für eine riesige, gemeinsame Geschichte schreiben. Ihre Aufgabe ist es, die gefährlichen Handlungslöcher, die Plot-Twists, die die gesamte Geschichte zum Absturz bringen könnten, oder die Seiten zu finden, die einem Dieb erlauben könnten, sich hineinzuschleichen und die Bücher zu stehlen. Dies ist die Sicherheitscode-Überprüfung.

Traditionell hatten Sie zwei Möglichkeiten, dies zu tun:

Der menschliche Redakteur: Ein müder Experte, der jedes Wort liest. Er ist gut darin, den Kontext zu verstehen, aber langsam und teuer.
Der automatisierte Rechtschreibprüfer: Ein Roboter, der nach bekannten bösen Wörtern scannt. Er ist schnell, schreit aber oft „FEHLER!", wenn nichts falsch ist (Fehlalarme), und übersieht subtile, clevere Tricks.

Diese Arbeit fragt: Kann eine neue Art von „Super-Leser" (Large Language Models oder LLMs) einen besseren Job leisten als die alten Rechtschreibprüfer?

Hier ist das, was die Forscher fanden, erklärt durch einfache Analogien:

1. Die Kandidaten: Wer erschien in der Bibliothek?

Die Forscher brachten sieben verschiedene „Super-Leser" (LLMs) mit. Einige sind allgemein nutzbar (gut darin, Gedichte und E-Mails zu schreiben), und einer ist ein „Reasoning-Optimiertes" Modell (speziell darauf trainiert, schrittweise wie ein Detektiv zu denken). Sie brachten auch die alten „automatischen Rechtschreibprüfer" (statische Analyse-Tools) mit, um zu sehen, wer gewinnt.

Das Ergebnis: Die Super-Leser schlugen die alten Rechtschreibprüfer in Grund und Boden. Der „Reasoning-Optimierte" Detektiv (genannt DeepSeek-R1) war der klare Champion, dicht gefolgt von GPT-4 (dem, das Sie vielleicht von ChatGPT kennen). Die alten Werkzeuge blieben im Staub zurück, hauptsächlich, weil sie bei komplexen Handlungssträngen (wie Race Conditions im Code) verwirrt werden, die ein Verständnis dafür erfordern, wie verschiedene Teile der Geschichte im Laufe der Zeit interagieren.

2. Der magische Prompt: Wie Sie fragen, ist wichtig

Genau wie beim Stellen einer Frage an einen Bibliothekar ist es wichtig, wie Sie den Super-Leser fragen. Die Forscher versuchten fünf verschiedene Arten zu fragen:

Die Basis-Anfrage: „Finde die Fehler."
Die kontextbezogene Anfrage: „Hier ist die Commit-Nachricht (die Notiz, die der Autor hinterlassen hat, über das, was sie geändert haben). Denken Sie schrittweise."
Die Spickzettel-Anfrage: „Hier ist eine Liste bekannter Verbrechenstypen (CWE-Liste). Suchen Sie nach diesen."

Der Gewinner:

Für DeepSeek-R1 war die beste Methode, ihm die Notiz des Autors (Commit-Nachricht) zu geben und ihm zu sagen, „schrittweise zu denken" (Chain-of-Thought). Es ist, als würde man einem Detektiv das Tagebuch des Verdächtigen geben und ihn bitten, den Tatort logisch zu durchgehen.
Für GPT-4 war die beste Methode, ihm den „Spickzettel" (die Liste der bekannten Verbrechen) zu übergeben. Es funktioniert am besten, wenn es eine spezifische Checkliste zu befolgen hat.

3. Die Mängel: Selbst Super-Leser machen Fehler

Die Forscher schauten nicht nur darauf, wer die Fehler fand; sie schauten darauf, wie die Super-Leser sie meldeten. Sie fanden zwei ausgeprägte Persönlichkeitsfehler:

GPT-4 (Der vage Dichter): Es findet oft das richtige Problem, beschreibt es aber auf eine neblige, vage Weise. Es könnte sagen: „Es gibt ein Sicherheitsrisiko irgendwo in dieser Datei", ohne auf die genaue Zeile hinzuweisen. Es ignoriert manchmal auch Anweisungen, wie zum Beispiel zu vergessen, „Keine Fehler gefunden" zu sagen, wenn keine vorhanden sind.
DeepSeek-R1 (Der selbstbewusste Faktenprüfer): Dieser ist sehr spezifisch. Er weist auf genaue Zeilennummern und Code-Schnipsel hin. Allerdings halluziniert er manchmal. Er könnte selbstbewusst auf Zeile 42 zeigen und sagen: „Diese Zeile ist gefährlich", obwohl Zeile 42 tatsächlich sicher ist. Es ist wie ein Detektiv, der so begierig ist, den Fall zu lösen, dass er Beweise erfindet, die es nicht gibt.

4. Das „Nadel im Heuhaufen"-Problem

Die Forscher entdeckten, dass diese Super-Leser Schwierigkeiten haben, wenn die Geschichte zu lang wird.

Kurze Dateien: Sie sind großartig darin, Fehler in kurzen, prägnanten Code-Dateien zu finden.
Lange Dateien: Wenn der Code länger wird (mehr „Tokens"), werden die Super-Leser abgelenkt. Sie übersehen die kleinen, gefährlichen Details, die in der Mitte einer riesigen Datei begraben sind. Es ist wie der Versuch, einen einzigen Tippfehler in einem 500-seitigen Roman zu finden; Ihre Augen glasieren über, und Sie übersehen ihn.

5. Das Komplexitäts-Paradoxon

Hier ist eine überraschende Wendung:

Normalerweise denken wir, komplexer Code sei schwieriger zu prüfen.
Aber für DeepSeek-R1 half komplexerer Code tatsächlich dabei, bestimmte Arten von Fehlern zu finden (außer solchen, die mit dem Speicher zusammenhängen).
Warum? Die Forscher vermuten, dass komplexer Code oft mehr „Hinweise" und Struktur innerhalb der Datei selbst hat. Der Super-Leser kann diese internen Hinweise nutzen, um durch das Problem zu reasoning. Einfacher, unordentlicher Code bietet weniger Hinweise, was es für die KI schwieriger macht, herauszufinden, was vor sich geht.

Das Fazit

Die Arbeit kommt zu dem Schluss, dass KI-Super-Leser leistungsstarke neue Werkzeuge sind, die derzeit besser sind als traditionelle automatische Scanner, wenn es darum geht, Sicherheitslücken im Code zu finden. Sie sind jedoch noch keine perfekten Ersatzlösungen für menschliche Redakteure.

DeepSeek-R1 ist am besten darin, Probleme durchzudenken, muss aber überwacht werden, damit es keine Fakten erfindet.
GPT-4 ist gut darin, Checklisten zu befolgen, kann aber zu vage sein.
Die Strategie: Der beste Ansatz ist nicht, Menschen zu ersetzen, sondern diese KI-Werkzeuge als ersten Durchgang zu verwenden. Lassen Sie die KI zuerst die kurzen, komplexen Dateien scannen, und lassen Sie dann menschliche Redakteure die Arbeit der KI überprüfen, insbesondere wenn die KI zu selbstbewusst oder zu vage wird.

Die Arbeit behauptet nicht, dass diese Werkzeuge bereit sind, die Bibliothek allein zu leiten, noch schlägt sie vor, dass sie perfekt sind. Sie zeigt einfach, dass sie ein vielversprechender neuer Assistent sind, der sorgfältiger Behandlung bedarf.

Titel: Ein Einblick in die Sicherheitscode-Review mit LLMs: Fähigkeiten, Hindernisse und Einflussfaktoren

Problemstellung
Die Sicherheitscode-Review ist ein kritischer, aber arbeitsintensiver Prozess, der für die Verhinderung von Datenpannen und finanziellen Verlusten unerlässlich ist. Obwohl Organisationen zunehmend Sicherheitsanalysen in die Code-Review integrieren, leiden bestehende automatisierte Tools (statische/dynamische/hybride Analyse) unter schlechter Generalisierung, hohen Raten an falsch positiven Ergebnissen und einer groben Detektionsgranularität. Darüber hinaus fehlen datengetriebenen Ansätzen, die auf traditionellem maschinellem Lernen oder Deep Learning basieren, oft die Robustheit aufgrund der Knappheit realistischer Trainingsdatensätze, was zu schlechten Leistungen bei realen Projekten führt. Obwohl Large Language Models (LLMs) in verschiedenen Aufgaben der Softwaretechnik vielversprechend sind, bleiben ihre spezifischen Fähigkeiten, Einschränkungen und die Faktoren, die ihre Leistung im feinabgestimmten Kontext der Sicherheitscode-Review beeinflussen, weitgehend unerforscht.

Methodik
Die Autoren führten eine empirische Studie durch, um das Potenzial von LLMs bei der Erkennung von Sicherheitsmängeln während der Code-Review zu bewerten. Die Studie nutzte einen manuell kuratierten Datensatz von 534 Code-Dateien (258 Python, 276 C/C++), die aus vier Open-Source-Projekten (OpenStack Nova/Neutron und Qt Base/Creator) stammen und 614 sicherheitsrelevante Review-Kommentare enthalten.

Bewertete Modelle: Sieben LLMs wurden getestet, darunter proprietäre Modelle (GPT-4, GPT-4 Turbo, Gemini Pro), Open-Source-Modelle (Llama 2 7B, Llama 2 70B) und ein auf Schlussfolgerungen optimiertes Modell (DeepSeek-R1).
Prompt-Engineering: Fünf verschiedene Prompt-Vorlagen wurden basierend auf Best Practices und früheren Strategien entwickelt:
1. Basis-Prompt ( $P_b$ ): Direkte Anweisung zur Code-Review.
2. Projektdaten ( $P_r$ ): Hinzugefügter Kontext des Projektnamens.
3. Allgemeine CWE-Anweisung ( $P_c$ ): Anweisung, CWE als Referenz zu verwenden.
4. Spezifische CWE-Anweisung ( $P_{cid}$ ): Bereitstellung einer Liste von Top-Level-CWEs.
5. Chain-of-Thought ( $P_{cot}$ ): Ein zweistufiger Prompt, der das Modell auffordert, aus einer Commit-Nachricht einen Code-Kontext zu generieren, bevor es auf Mängel analysiert wird. Eine „Guardrail"-Version ( $P_{cot-guardrail}$ ) wurde ebenfalls getestet, um den Einfluss des generierten Kontexts zu isolieren.
Bewertungsmetriken: Die Antworten wurden manuell in vier Kategorien eingeteilt: Instrumentell (genaue Fehlerart, -ort und -beschreibung), Hilfreich (teilweise genau), Irreführend (fehlende Erkennung oder falsch negative Ergebnisse) und Unsicher. Die Metriken umfassten I-Score, IH-Score und M-Score. Die Konsistenz wurde über die Antwort-Entropie bei drei experimentellen Durchläufen gemessen.
Analyse: Die Studie verglich die Leistung von LLMs mit state-of-the-art statischen Analyse-Tools (z. B. CodeQL, Bandit, CppCheck). Für die leistungsstärksten Modelle identifizierte eine linguistische Analyse Qualitätsprobleme (z. B. Halluzinationen, Vagheit). Schließlich wurden kumulative Link-Regressionmodelle erstellt, um den Einfluss von 11 Faktoren (z. B. Token-Anzahl, Code-Komplexität, Fehlertyp) auf die Leistung zu analysieren.

Hauptbeiträge

Feinabgestimmte Bewertung: Bereitstellung einer umfassenden Bewertung populärer LLMs in der Sicherheitscode-Review, die über eine binäre Klassifizierung hinausgeht, um die Lokalisierung von Fehlern, deren Beschreibung und Vorschläge zur Behebung zu bewerten.
Analyse der Nichtdeterminiertheit: Messung des Einflusses der Nichtdeterminiertheit von LLMs auf die Konsistenz der Ergebnisse der Sicherheitscode-Review.
Quantifizierung von Qualitätsproblemen: Identifizierung und Quantifizierung spezifischer Qualitätsprobleme, einschließlich Halluzinationen (faktisch und bezüglich der Treue), in den Antworten der leistungsstärksten Modelle.
Analyse des Faktoreinflusses: Durchführung der ersten Regressionsanalyse zur statistischen Validierung, wie spezifische Code- und Projektkennwerte die Leistung von LLMs in diesem Bereich beeinflussen.

Ergebnisse

Leistung im Vergleich zu Baselines: LLMs schnitten in der Sicherheitscode-Review deutlich besser ab als state-of-the-art statische Analyse-Tools. Unter den LLMs übertraf das auf Schlussfolgerungen optimierte Modell (DeepSeek-R1) allgemeine Modelle.
Top-Performer: DeepSeek-R1 erzielte die beste Gesamtleistung, gefolgt von GPT-4 (über die ChatGPT-Plattform).
- Optimale Prompts: DeepSeek-R1 schnitt am besten mit einem Prompt ab, der die Commit-Nachricht und Chain-of-Thought (CoT)-Anleitung kombinierte ( $P_{cot-guardrail}$ ). GPT-4 (ChatGPT) schnitt am besten mit einem Prompt ab, der eine spezifische Liste von CWEs enthielt ( $P_{cid}$ ).
Qualitätsprobleme:
- GPT-4 (ChatGPT): Erzeugte häufig vage Formulierungen und hatte Schwierigkeiten, Anweisungen zu befolgen (z. B. fehlende Zeilennummern), obwohl es weniger faktische Fehler bezüglich Code-Details aufwies.
- DeepSeek-R1: Neigte eher dazu, ungenaue Code-Details zu generieren (z. B. falsche Zeilennummern oder Funktionsnamen) und zeigte eine höhere Rate an „Incorrect Fact"-Halluzinationen, obwohl es über bessere Fähigkeiten zur Befolgung von Anweisungen verfügte.
Einflussfaktoren:
- Token-Anzahl: LLMs waren besser darin, Fehler in Dateien mit weniger Tokens zu identifizieren; die Leistung nahm im Allgemeinen mit steigender Token-Anzahl ab.
- Annotationen: Das Vorhandensein sicherheitsrelevanter Annotationen im Code verbesserte die Detektionsfähigkeiten.
- Komplexität: Eine höhere Code-Komplexität korrelierte bei DeepSeek-R1 für bestimmte Fehlertypen (mit Ausnahme von speicherbezogenen) mit verbesserten Detektionsfähigkeiten, im Gegensatz zur Annahme, dass Komplexität die Detektion immer behindert.
- Konsistenz: Modelle mit höheren Detektionsfähigkeiten (DeepSeek-R1, GPT-4 ChatGPT) zeigten im Vergleich zu weniger leistungsfähigen Modellen eine geringere Konsistenz (höhere Entropie) über die Durchläufe hinweg.

Bedeutung und Behauptungen
Die Arbeit behauptet, dass aktuelle LLMs zwar noch kein Ersatz für menschliche Reviewer sind, aber als leistungsstarke Hilfsmittel dienen, die bei der Erkennung von Sicherheitsmängeln traditionelle statische Analyse-Tools deutlich übertreffen. Die Studie hebt hervor, dass die Wirksamkeit von LLMs stark vom Prompt-Engineering abhängt (insbesondere die Einbeziehung von Commit-Nachrichten, CoT oder CWE-Listen) sowie von den spezifischen Eigenschaften des zu reviewenden Codes (Token-Anzahl, Komplexität, Annotationen).

Die Autoren betonen, dass die Nichtdeterminiertheit von LLMs ein zweischneidiges Schwert ist: Modelle, die zu tieferen Schlussfolgerungen (und damit besserer Detektion) fähig sind, neigen dazu, inkonsistentere Ausgaben zu produzieren. Sie kommen zu dem Schluss, dass eine mehrschichtige Review-Strategie notwendig ist, bei der LLMs die Erstprüfung von Code mit geringem Schwierigkeitsgrad (weniger Tokens) übernehmen, während menschliche Experten sich auf Code mit hohem Schwierigkeitsgrad konzentrieren und die Ergebnisse der LLMs validieren. Die Studie unterstreicht zudem die Notwendigkeit zukünftiger Arbeiten, um Halluzinationen bezüglich Code-Details zu adressieren und die Stabilität von LLM-Ausgaben zu verbessern, ohne die Detektionsempfindlichkeit zu beeinträchtigen.