LLMs bewerten Code-Sicherheit nach Kommentaren, nicht nach Logik

TL;DR

• Neue Forschung zeigt, dass Large Language Models (LLMs) menschliche kognitive Verzerrungen wie den „Halo-Effekt“ nutzen, um die Sicherheit von Softwarecode zu bewerten.
• Diese Modelle übersehen oft kritische Schwachstellen, wenn der Code professionelle Kommentare enthält oder gängigen Stilmustern folgt, was erhebliche Sicherheitslücken schafft.

Hintergrund

Softwaresicherheit hängt davon ab, Schwachstellen zu identifizieren – Fehler im Code, die Angreifer ausnutzen können, um Daten zu stehlen oder Systeme zum Absturz zu bringen. Traditionell erforderte dies eine manuelle Überprüfung oder starre automatisierte Tools. Heute nutzen Entwickler LLMs, um Code schneller zu scannen. LLMs werden jedoch mit von Menschen geschriebenen Texten trainiert. Das macht sie anfällig für „kognitive Heuristiken“ – mentale Abkürzungen, die Menschen nutzen, um schnelle Entscheidungen zu treffen. Wenn eine KI diese Abkürzungen übernimmt, hört sie auf, die tatsächliche Logik zu analysieren, und beginnt, Annahmen basierend auf dem äußeren Erscheinungsbild zu treffen.

Was passiert ist

Eine systematische Studie hat gezeigt, dass LLMs für dieselben kognitiven Verzerrungen anfällig sind, die auch menschliche Programmierer bei der Erkennung von Schwachstellen plagen [^1]. Die Forscher untersuchten mehrere spezifische Heuristiken, darunter die „Verfügbarkeitsheuristik“ und den „Halo-Effekt“. Im Kontext der Programmierung tritt der Halo-Effekt auf, wenn ein Modell ein Stück Code als sicher wahrnimmt, nur weil es „sauber“ aussieht. Wenn eine Funktion eine gut formatierte Dokumentation, professionelle Variablennamen und eine klare Struktur hat, ist es deutlich wahrscheinlicher, dass das LLM sie als sicher einstuft – selbst wenn eine logikbasierte Schwachstelle wie ein Buffer Overflow vorliegt. Dies deutet darauf hin, dass das LLM die Absicht des Entwicklers über die Code-Ausführung stellt. Durch das bloße Hinzufügen eines Kommentars, der behauptet, eine Variable sei „sanitized“, konnten Forscher das Modell austricksen, sodass es eine offensichtliche Sicherheitslücke ignorierte [^1]. Dies spiegelt frühere Erkenntnisse wider, wonach KI-gestützte Coding-Tools oft unsicheren Code generieren, weil sie das Nachahmen von Mustern aus ihren Trainingsdaten über die Einhaltung strenger Sicherheitsprinzipien stellen [^2].

Die Forschung hob auch die „Ankerheuristik“ hervor. Wenn einem Modell ein erster Vorschlag oder ein spezifischer Kontext präsentiert wird, neigt es dazu, seine gesamte Analyse an diesem Ausgangspunkt zu verankern. Wenn der Prompt suggeriert, dass der Code Teil einer hochwertigen Library ist, sinkt die Skepsis des Modells. Die Modelle hatten auch Probleme mit der „Repräsentativitätsheuristik“, bei der sie davon ausgingen, ein Codeblock sei sicher, weil er wie andere sichere Codeblöcke aussah, die sie während des Trainings gesehen hatten. Dieses Pattern-Matching-Verhalten ersetzt die rigorose, schrittweise Logik, die für ein echtes Sicherheits-Audit erforderlich ist. Die Auswirkungen sind drastisch: Aktuelle LLM-basierte Sicherheitstools führen keine objektive Analyse durch. Stattdessen führen sie eine Hochgeschwindigkeitsversion eines menschlichen „Vibe-Checking“ durch. Sie suchen nach Signalen für guten Code statt nach der Substanz von sicherem Code. Das macht sie zwar nützlich, um häufige, sich wiederholende Fehler zu finden, aber es macht sie auch gefährlich einfach zu umgehen für einen Angreifer, der weiß, wie man bösartigen Code professionell aussehen lässt.

Warum es wichtig ist

Die Entdeckung dieser Verzerrungen markiert einen entscheidenden Wendepunkt für die KI-integrierte Entwicklung. Wenn wir uns darauf verlassen, dass LLMs als finale Gatekeeper für die Softwaresicherheit fungieren, automatisieren wir effektiv menschliches Versagen. Die „semantische Lücke“ zwischen dem, was ein Modell sagt, und dem, was der Code tatsächlich tut, ist der Ort, an dem sich die gefährlichsten Schwachstellen verbergen. Wenn ein Modell einem Kommentar mehr vertraut als einem Befehl, erzeugt dies ein falsches Sicherheitsgefühl, das wohl gefährlicher ist, als gar keine automatisierte Prüfung zu haben. Entwickler könnten aufhören, selbst nach Fehlern zu suchen, in der Annahme, die KI hätte den Code „bereinigt“. Dieses Problem betrifft auch die Software-Lieferkette. Da immer mehr Unternehmen KI nutzen, um Libraries von Drittanbietern zu prüfen, wächst das Risiko einer „Adversarial Aesthetics“. Ein Angreifer könnte eine bösartige Library zu einem Open-Source-Projekt beisteuern und sicherstellen, dass der Code perfekt formatiert und mit beruhigenden Beschreibungen ausführlich kommentiert ist. Wenn das automatisierte Audit-Tool ein durch diese Heuristiken voreingenommenes LLM ist, wird der bösartige Beitrag problemlos akzeptiert [^2].

Um dies zu beheben, muss die Branche zu hybriden Systemen übergehen. Wir können LLMs nicht als eigenständige Sicherheitsexperten behandeln. Stattdessen müssen sie mit formalen Verifizierungstools gekoppelt werden – Software, die mathematische Beweise nutzt, um die Logik zu prüfen –, um die „Intuition“ der KI in der objektiven Realität zu verankern. Wir müssen auch ändern, wie wir diese Modelle trainieren und prompten. Anstatt zu fragen „Ist dieser Code sicher?“, sollten wir das Modell zwingen, den Datenfluss und die Zustandsübergänge Schritt für Schritt zu erklären, was helfen kann, die Abhängigkeit von oberflächlichen Heuristiken zu durchbrechen. Die Vorurteile der KI bezüglich der Codequalität zu erkennen, ist der erste Schritt zum Aufbau widerstandsfähiger Tools, die sich nicht so leicht von einem gut platzierten Kommentar täuschen lassen. Wir bewegen uns auf eine Welt zu, in der „sicher aussehen“ zu einem brauchbaren Ersatz für „sicher sein“ wird.

Ein Beispiel aus der Praxis

Stell dir einen Entwickler namens Marcus vor, der eine Funktion für den Upload von Benutzerprofilen schreibt. Er nutzt ein LLM, um seine Arbeit zu überprüfen. Die Funktion enthält einen klassischen „Path Traversal“-Fehler, der es einem Angreifer ermöglichen würde, sensible Systemdateien zu überschreiben. Marcus hat jedoch sehr professionell wirkenden Code geschrieben. Er hat einen detaillierten Docstring eingefügt, beschreibende Variablennamen wie user_provided_path_safe verwendet und einen Kommentar hinzugefügt: // Standard security check applied below. Wenn das LLM den Code scannt, setzt der „Halo-Effekt“ ein. Es sieht die professionelle Formatierung und den beruhigenden Kommentar. Weil der Code so aussieht, als hätte ihn ein Senior Engineer geschrieben, geht das LLM davon aus, dass er korrekt ist. Es bemerkt nicht, dass der von Marcus erwähnte „Sicherheitscheck“ logisch fehlerhaft ist und den Angriff nicht stoppt. Die KI gibt grünes Licht, und Marcus vertraut dem Tool und schiebt den Code in die Production. Die KI hat nicht die Logik geprüft; ihr gefiel nur, wie der Code sprach.

Passende Produkte

Wir empfehlen diesen Text, weil er den rigorosen, manuellen Audit-Rahmen bietet, den LLMs derzeit zugunsten oberflächlicher Heuristiken umgehen.