Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions
Diese groß angelegte Messstudie zeigt, dass LLMs aufgrund systemischer Verzerrungen zugunsten bestimmter risikobehafteter Versionen häufig anfällige und inkompatible Versionen von Drittanbieterbibliotheken in generiertem Python-Code angeben, wodurch eine kritische, bisher übersehene Angriffsfläche in der KI-gestützten Softwareentwicklung aufgedeckt wird.
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 stellen einen überaus intelligenten und unglaublich schnellen persönlichen Assistenten ein, um Code für Ihre Softwareprojekte zu schreiben. Dieser Assistent, der von einem Large Language Model (LLM) angetrieben wird, ist hervorragend darin, die Logik zu schreiben: „So verschließen Sie eine Tür" oder „So senden Sie eine Nachricht".
Aber es gibt einen Haken. Damit der Code funktioniert, muss der Assistent „Werkzeuge" (Drittanbieter-Bibliotheken) verwenden, die bereits existieren. Das Problem, das diese Arbeit untersucht, besteht darin, dass der Assistent nicht einfach die Werkzeuge greift; er greift sich spezifische, veraltete und manchmal defekte Versionen dieser Werkzeuge, und das, ohne dass Sie es merken.
Hier ist eine Aufschlüsselung der Studienergebnisse mit einfachen Analogien:
1. Das „Rezept" versus die „Einkaufsliste"
Die Forscher testeten zwei Arten, den Assistenten um Code zu bitten:
- Der „Inline"-Modus: Sie bitten um ein Code-Snippet, und der Assistent schreibt den Code und fügt neben jedem Werkzeug eine kleine Notiz hinzu, die besagt: „Verwenden Sie Werkzeug X, Version 1.0."
- Der „Manifest"-Modus: Sie bitten den Assistenten, ein Code-Snippet und eine separate Einkaufsliste (eine
requirements.txt-Datei) für die Werkzeuge zu schreiben.
Das Ergebnis:
Wenn nach der „Inline"-Notiz gefragt wurde, war der Assistent sehr bestrebt, exakte Versionen anzugeben (in 95 % der Fälle). Aber wenn nach der „Einkaufsliste" gefragt wurde, wurde er plötzlich faul und vage und ließ die Versionsnummern oft leer (nur in 6 % bis 59 % der Fälle).
- Analogie: Es ist wie ein Koch, der, wenn er gebeten wird, ein Rezept zu schreiben, sagt: „Verwenden Sie genau Salz aus der Jahrgang 2015." Aber wenn er gebeten wird, eine Einkaufsliste für die ganze Küche zu schreiben, schreibt er einfach nur „Salz" und überlässt es Ihnen, herauszufinden, welches Jahrgangssalz Sie kaufen sollen.
2. Das Problem mit der „abgelaufenen Milch" (Sicherheitsrisiken)
Die Studie ergab, dass der Assistent, wenn er doch eine spezifische Version auswählt, oft eine wählt, die gefährlich ist.
- Die Statistik: In 37 % bis 56 % der Fälle hatte die vom Assistenten ausgewählte spezifische Version eine bekannte Sicherheitslücke (ein „CVE").
- Die Schwere: Die meisten dieser Lücken hatten eine „kritische" oder „hohe" Schwere.
- Der Twist: Diese Lücken waren kein Geheimnis. Sie waren öffentlich bekannt, bevor der Assistent überhaupt trainiert wurde. Der Assistent wusste einfach nicht, dass er sie vermeiden sollte.
- Analogie: Stellen Sie sich vor, der Assistent ist ein Zeitreisender, der immer Milch wählt, die vor drei Jahren abgelaufen ist. Obwohl das Haltbarkeitsdatum Jahre zuvor auf der Packung gedruckt war, reicht der Assistent Ihnen immer wieder dieselbe abgelaufene Milch, in dem Glauben, sie sei frisch.
3. Der „Konvergenz"-Effekt (Alle wählen dasselbe Schlechte)
Man könnte denken, verschiedene KI-Modelle würden unterschiedliche Versionen auswählen. Das tun sie nicht.
- Das Ergebnis: Alle zehn getesteten Modelle (von Google, OpenAI, Alibaba usw.) konvergierten auf exakt dieselbe kleine Gruppe riskanter Versionen. Wenn der Assistent „Werkzeug X" wählt, wählt er fast immer „Version 2.31.0", selbst wenn neuere, sicherere Versionen existieren.
- Analogie: Es ist, als würde jede einzelne Person in einer Stadt, unabhängig von ihrem Hintergrund, beschließen, genau dasselbe Paar Schuhe zu kaufen, von dem bekannt ist, dass die Sohle defekt ist. Es ist kein Zufall; es ist eine gemeinsame Gewohnheit, die aus denselben alten Lehrbüchern gelernt wurde.
4. Das Problem mit dem „kaputten Schlüssel" (Kompatibilität)
Selbst wenn das Werkzeug nicht gefährlich ist, passt es vielleicht nicht.
- Das Ergebnis: Die vom Assistenten ausgewählten Versionen ließen sich oft nicht installieren oder funktionierten nicht mit dem Code, den sie geschrieben hatten.
- Statischer Check: Der Code ließ sich gar nicht installieren (wie der Versuch, einen quadratischen Pfosten in ein rundes Loch zu stecken).
- Dynamischer Check: Selbst wenn er installiert wurde, stürzte der Code ab, sobald Sie versuchten, ihn auszuführen.
- Die Ursache: Die Assistenten lieben es, sehr alte Versionen von Werkzeugen zu wählen. Diese alten Versionen verlassen sich auf Teile des Computersystems, die in modernen Computern entfernt wurden.
- Analogie: Der Assistent schreibt einen Code, der besagt: „Schalten Sie das Licht ein", gibt aber eine Glühbirne aus dem Jahr 1990 an, die einen Sockel benötigt, der in Ihrem Haus von 2026 nicht existiert. Der Code ist perfekt, aber die Glühbirne lässt sich nicht einschrauben.
5. Warum können wir dem Assistenten nicht einfach „sagen", dass er besser sein soll?
Die Forscher versuchten ein paar Dinge, um dies zu beheben:
- Der „Bitte seien Sie sicher"-Prompt: Sie sagten dem Assistenten: „Bitte verwenden Sie keine Versionen mit Sicherheitslöchern."
- Ergebnis: Es funktionierte nicht. Der Assistent wählte immer noch die schlechten Versionen.
- Warum: Der Assistent „vergisst" die Regeln nicht; er ist einfach nicht mit einer Live-Datenbank von Sicherheitswarnungen verbunden. Es ist, als würde man einen Schüler bitten, der ein Lehrbuch von 2023 auswendig gelernt hat, ein neues Gesetz zu vermeiden, das 2025 erlassen wurde. Er hat die Information buchstäblich nicht im Kopf.
- Die „Externe Anker"-Lösung: Als die Forscher den Assistenten zwangen, eine vorab genehmigte Liste sicherer Versionen zu verwenden (wie eine strenge Einkaufsliste, die von einem Menschen bereitgestellt wurde), verschwanden die Probleme.
- Ergebnis: Die Sicherheitsrisiken sanken, und der Code funktionierte tatsächlich.
Das Fazit
Die Arbeit kommt zu dem Schluss, dass LLMs hervorragend darin sind, die „Logik" von Code zu schreiben, aber schrecklich darin sind, die „Lieferkette" der Werkzeuge zu verwalten.
Sie agieren wie eine hilfsbereite, aber unzuverlässige Bibliothekarin, die Ihnen ein Buch aushändigt, das perfekt aussieht, aber tatsächlich eine gefährliche, veraltete Ausgabe ist. Sie können den spezifischen Versionsnummern, die sie vorschlagen, nicht vertrauen. Sie müssen sie als Entwurf behandeln und die Versionsnummern vor der Verwendung immer mit einem Sicherheitstool überprüfen.
Das Problem ist nicht, dass die KI „dumm" ist; es ist, dass die KI auf alten Daten trainiert wurde, die sie dazu bringen, beliebte, aber alte Versionen zu bevorzugen, und dass ihr eine Live-Verbindung zu aktuellen Sicherheitswarnungen fehlt. Solange die KI nicht mit Live-Sicherheitstools verbunden ist, muss der menschliche Entwickler derjenige sein, der die Ablaufdaten überprüft.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.