Technische Samenvatting: Correcte Code, Kwetsbare Dependencies

Probleemstelling

Grote Taalmodellen (LLMs) zijn onlosmakelijk geworden van softwareontwikkelingsworkflows en genereren routinematig code die importen van third-party libraries (TPL) bevat, voorzien van specifieke versie-identificatoren. Hoewel eerdere onderzoeken uitgebreid de logische beveiliging van gegenereerde code (bijv. CWE-kwetsbaarheden) en het bestaan van hallucinatie van pakketnamen hebben bestudeerd, blijft de versiedimensie grotendeels onontgonnen. Specifiek is onbekend of de specifieke releaseversies van correct benoemde libraries die door LLMs worden aanbevolen, veilig, compatibel of zelfs geldig zijn.

Dit artikel identificeert een kritiek risicogebied: LLMs kunnen syntactisch correcte code genereren die een libraryversie vastzet die bekende Common Vulnerabilities and Exposures (CVE's) bevat, of een versie die incompatibel is met het gegenereerde API-gebruik. Omdat deze keuzes impliciet en op grote schaal worden gemaakt tijdens codegeneratie, kunnen ze systeemrisico's voor beveiliging en installatiefouten stilzwijgend doorgeven aan downstream-projecten.

Methodologie

De auteurs presenteren PinTrace, de eerste grootschalige meetstudie van door LLMs gespecificeerde libraryversies. De studie evalueert 10 diverse LLMs (waaronder gesloten bronmodellen zoals GPT-5.4 en open-sourcemodellen zoals Qwen3 en Llama-4) op een gecureerde benchmark van 1.000 real-world Stack Overflow-programmeertaken.

Experimenteel Ontwerp

De studie hanteert twee promptmodi om veelvoorkomende ontwikkelaarsinteracties te weerspiegelen:

1. Inline Modus: De LLM annotatieert importen met versiecommentaren (bijv. import lib # version==x.y.z).
2. Expliciete Modus: De LLM genereert een requirements.txt manifestbestand naast de code.

Het analyseproces bestaat uit vijf fasen:

1. Generatie: Code produceren voor elke taak onder beide modi.
2. Extractie: Library-referenties en versiespecificaties parseren.
3. Validatie: Verificatie tegen PyPI om ervoor te zorgen dat versies gepubliceerde releases zijn (hallucinaties filteren).
4. Kwetsbaarheidscontrole: Kruisverwijzing van geldige versies met de Open Source Vulnerability (OSV)-database om CVE's en CVSS-zwaarte te identificeren.
5. Compatibiliteitscontrole:
   • Statisch: Poging tot installatie in geïsoleerde virtuele omgevingen en uitvoeren van statische typecontrole (ty).
   • Dynamisch: Uitvoeren van testsuites uit de BigCodeBench-benchmark om runtime-correctheid te verifiëren.

De studie omvat ook robuustheidstests over Python-versies (3.8–3.14), een diagnose-experiment waarbij naburige versies worden vervangen om oorzaken van fouten te isoleren, en mitigatieproeven die veiligheidsinstructies en externe versie-ankering testen.

Belangrijkste Bijdragen

1. Meetstudie: Een uitgebreide evaluatie van het gedrag bij versiespecificatie, geldigheid, blootstelling aan kwetsbaarheden en compatibiliteit over 10 modellen en 1.000 taken.
2. Bewijs van Systematische Bias: Empirisch bewijs dat LLMs convergeren naar een kleine set risicovolle, verouderde versies over verschillende modelfamilies heen, gedreven door bias in het trainingssignaal in plaats van geïsoleerde modelfouten.
3. Diagnose van Oorzaak: Een gecontroleerd experiment dat aantoont dat installatiefouten voornamelijk toe te schrijven zijn aan versiekeuze (keuze van incompatibele/oude versies) en niet aan gebreken in de gegenereerde code-logica.
4. Analyse van Mitigatie: Een karakterisering van interventies op promptniveau, waarbij wordt aangetoond dat veiligheidsinstructies in natuurlijke taal inefficiënt zijn, terwijl externe versie-ankering de risico's aanzienlijk vermindert.
5. Open Bronnen: Publicatie van de PinTrace-dataset en het evaluatieproces voor reproduceerbaar onderzoek.

Belangrijkste Resultaten

1. Gedrag bij Versiespecificatie (RQ1)

• Format-Aanbod: Versieannotatie wordt gedreven door het outputformaat, niet door engineeringintentie. In Inline-modus specificeren modellen versies voor 26,83%–95,18% van de referenties. In Expliciete modus (manifestgeneratie) daalt dit tot 6,45%–59,19%, waarbij veel modellen versies volledig weglaten.
• Convergentie: Modellen convergeren naar een smalle band van populaire releases. Bijvoorbeeld, requests==2.31.0 en django==6.0.1 worden door bijna alle modellen gespecificeerd.
• Temporele Achterstand: Gespecificeerde versies lopen achter op de kenniscutoffs van het model met 9 tot 31 maanden. Modellen kiezen bij voorkeur oudere versies die meer trainingssignaal hebben opgebouwd.
• Geldigheid: Hoewel de meeste inline-gespecificeerde versies geldig zijn, zijn 7%–16% gehallucineerd (ongeldige PyPI-releases), vaak door het weglaten van suffixen (bijv. 4.8.0 in plaats van 4.8.0.74).

2. Blootstelling aan Kwetsbaarheden (RQ2)

• Hoge Blootstelling: Bij inline-prompting bevat 36,70%–55,70% van de taken ten min één versie met een bekende CVE.
• Zwaarte: 62,75%–74,51% van deze kwetsbare versies wordt beoordeeld als Kritiek of Hoog van zwaarte.
• Vermijdbaarheid: In 72,27%–91,37% van de gevallen werden de bijbehorende CVE's publiek bekendgemaakt voordat de kenniscutoff van het model werd bereikt, wat aangeeft dat de blootstelling vermijdbaar is maar niet door het model wordt herkend.
• Structureel Risico: 95,11% van de kwetsbare (library, versie)-paren heeft geen CVE-vrij alternatief binnen dezelfde hoofdversie-tak, wat betekent dat simpele patch-updates het risico niet kunnen oplossen.

3. Compatibiliteit (RQ3)

• Statische Compatibiliteit: De percentages lopen uiteen van 19,70% tot 63,20% in inline-modus. De dominante oorzaak van fouten is installatiefout van dependencies, vaak door het ontbreken van distutils in Python 3.12+-omgevingen (een gevolg van het selecteren van oudere versies).
• Dynamische Compatibiliteit: De doorlooppercentages zakken naar 6,49%–48,62% in inline-modus. De meeste taken falen vóór uitvoering door installatiefouten.
• Diagnose: Een substitutie-experiment bevestigde dat het vervangen van de door de LLM gespecificeerde versie door een naburige release installatiefouten oplost in 17,19%–55,00% van de gevallen, wat bewijst dat de code-logica vaak correct is maar de versiekeuze gebrekkig.

4. Mitigatie

• Prompting: Het toevoegen van veiligheidsinstructies in natuurlijke taal ("vermijd kwetsbare versies") levert verwaarloosbare verbetering op (<2,2% reductie in blootstelling).
• Externe Ankering: Het injecteren van vooraf berekende veilige versies in de prompt vermindert de blootstelling aan kwetsbaarheden aanzienlijk (tot ~10–27%) en verbetert de statische compatibiliteit tot 80%–93%.

Betekenis en Beweringen

Het artikel betoogt dat versiekeuze door LLMs een eerstegraads, eerder over het hoofd gezien risicogebied is. De bevindingen onthullen dat:

1. Het risico systemisch is, niet idiosyncratisch: De convergentie naar dezelfde kwetsbare versies over alle modelfamilies heen wijst op een gedeelde bias in het trainingssignaal, waardoor het onmogelijk is om dit te mitigeren door simpelweg modellen te wisselen.
2. Het probleem een 'grounding'-kloof is, geen veiligheidsalignement-kloof: Aangezien de meeste CVE's al bekend waren vóór de training, ligt het falen in het onvermogen van het model om versie-identificatoren tijdens inferentie te koppelen aan hun beveiligingsstatus.
3. Prompting is onvoldoende: Instructies in natuurlijke taal kunnen de kloof tussen versiekeuze en beveiligingskennis niet overbruggen.
4. Externe tooling is vereist: De auteurs concluderen dat het aanpakken van dit risico externe mechanismen vereist (bijv. SCA-tools, versie-ankering) in plaats van te vertrouwen op de interne kennis van de LLM.

De auteurs hebben deze bevindingen gedeeld met de geëvalueerde modelproviders (waaronder OpenAI, Alibaba en Moonshot AI), waarvan enkelen het probleem hebben erkend. Het artikel pleit voor de integratie van beveiliging en compatibiliteitsbeoordeling op versieniveau in standaard LLM-evaluatiebenchmarks.