💻 computer science

False Security Confidence in Benign LLM Code Generation

Dit technische rapport introduceert het concept van "False Security Confidence" (FSC) om te bestuderen hoe vaak kwetsbare code in functioneel correcte LLM-gegenereerde output voorkomt bij normale taken, en schetst een meetkader om dit fenomeen te analyseren zonder expliciete aanvalsdruk.

Oorspronkelijke auteurs: Xiaolei Ren

Gepubliceerd 2026-04-21

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Xiaolei Ren

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, maar soms onvoorspelbare kok hebt: een kunstmatige intelligentie (LLM) die voor je kookt. Je vraagt hem om een perfecte spaghetti bolognese.

Deze kok levert een bord met spaghetti aan. Het ziet er prachtig uit, het ruikt heerlijk, en als je het proeft, smaakt het precies zoals je wilt. Je denkt: "Perfect! Dit is een geslaagd gerecht." Je bent tevreden en zet het op tafel.

Maar... er zit een onzichtbaar gif in de saus. Je ziet het niet, je proeft het niet, en de kok zelf lijkt ook niet te weten dat het erin zit. Als je het eet, word je ziek.

Dit is precies waar dit paper over gaat.

De auteurs noemen dit fenomeen "Valse Veiligheidszekerheid" (in het Engels: False Security Confidence of FSC).

Hier is de uitleg in simpele taal, met een paar analogieën:

1. Het probleem: "Het werkt, dus het is veilig"

Vaak kijken we naar code die door AI is geschreven en zeggen: "Ja, de computer doet wat ik vraag, de knoppen werken, de cijfers kloppen." We denken dan: "Gefeliciteerd, het is veilig."

Maar in de digitale wereld kan code perfect werken (de spaghetti smaakt goed), maar toch een enorme beveiligingslek hebben (het gif). De AI heeft de taak goed gedaan, maar de beveiliging vergeten. Omdat het "werkt", vertrouwen we het te snel. Dat is de Valse Veiligheidszekerheid.

2. De nieuwe maatstaf: "Hoe vaak zit er gif in de goede maaltijden?"

Vroeger keken onderzoekers alleen naar: "Hoe vaak maakt de AI een fout?" of "Hoe vaak is de code onveilig?"

De auteurs zeggen: "Nee, dat is niet genoeg." Ze willen weten: Van alle gerechten die er perfect uitzien en goed smaken, hoeveel hebben er eigenlijk gif?

Ze noemen dit de FSC-snelheid.

Stel, de AI maakt 100 borden spaghetti.
90 zijn perfect en veilig.
5 zijn volledig mislukt (niet eetbaar).
5 zien er perfect uit, smaken goed, maar zijn dodelijk (gif).

De oude manier van meten zou zeggen: "5% is onveilig."
De nieuwe manier (FSC) zegt: "Kijk eens, van de 95 borden die leken te slagen, waren er 5 dodelijk. Dat is een groot risico voor wie denkt dat het veilig is!"

3. Drie verschillende keukens (Drie ecosystemen)

De auteurs zeggen dat dit probleem in drie verschillende situaties anders voorkomt:

De Algemene Keuken: Je vraagt om een simpele taak, zoals "tel de getallen op". Hier is het gif vaak verborgen in de details die niemand verwacht.
De Restaurantkeuken (Deployments): Hier draait het om echte situaties, zoals wachtwoorden beheren of toegang geven. De code werkt misschien lokaal, maar zodra het in het echte restaurant (de server) staat, breekt de beveiliging.
De Veiligheidskeuken: Je vraagt de AI expliciet: "Maak een onkraakbare kluis." Het is eng, maar soms maakt de AI een kluis die eruitziet als een kluis, maar waar een simpele sleutel in past. De AI begrijpt de opdracht, maar faalt toch in de uitvoering.

4. De "Onzichtbare Gifdop" (FSC-hard)

Soms is het gif zo goed verstopt dat zelfs de geavanceerde scanners (de veiligheidssoftware) het niet zien.

Normaal onveilig: De scanner zegt: "Let op, hier zit een lek!" (De kok krijgt een waarschuwing).
FSC-hard: De scanner zegt: "Alles goed!" en de AI zegt: "Alles goed!" Maar er zit toch gif in.

Dit is het gevaarlijkste deel. Omdat zowel de mens als de computer denken dat het veilig is, wordt het echt gegeten. De auteurs noemen dit FSC-hard: het is hard om te vinden omdat de standaardtools het missen.

Waarom is dit belangrijk?

Dit paper is geen onderzoek dat zegt: "Kijk, we hebben een nieuwe hack gevonden." Het is eerder een waarschuwingsbord.

Het zegt: "Houd op met alleen te kijken of de code 'werkt'. Kijk ook of het veilig is, zelfs als het werkt. Want als we alleen kijken naar wat er 'werkt', geven we ons een vals gevoel van veiligheid, en dat kan leiden tot grote problemen."

Kort samengevat:
De AI kan een perfecte auto bouwen die rijdt en stopt. Maar als de remmen niet werken als je hard rijdt, is het een dodelijke auto. Dit paper waarschuwt ons om niet alleen te kijken of de auto rijdt, maar ook om te testen of de remmen werken, zelfs als de auto er perfect uitziet.

Titel: Valse Veiligheidsvertrouwen in Benigne LLM-codegeneratie

Auteur: Xiaolei Ren (Macau University of Science and Technology)
Datum: April 2026

1. Het Probleem

Huidige evaluaties van Large Language Models (LLM's) voor codegeneratie gaan er vaak ten onrechte van uit dat functionele correctie en veiligheidscorrectie natuurlijk met elkaar verbonden zijn. In de praktijk vertonen deze twee domeinen echter vaak een discrepantie. Een gegenereerd programma kan:

Unit-tests doorstaan.
De verwachte output produceren.
Stijlvol en correct lijken.

Toch kan deze code kwetsbaarheden bevatten, zoals onveilige query-construkties, onveilige verwerking van inloggegevens, exploitabele deserialisatielogica of misconfiguraties die alleen zichtbaar zijn in een specifieke implementatie-omgeving.

Dit creëert een misleidend gevoel van veiligheid: zodra een sample als "functioneel correct" wordt bestempeld, neigen gebruikers en onderzoekers er onbewust naar om de kwaliteit en veiligheid ervan te overschatten. Dit paper introduceert het concept False Security Confidence (FSC): het fenomeen waarbij vertrouwen in de veiligheid wordt gewekt door functioneel succes, terwijl het artifact in feite onveilig is.

2. Methodologie en Raamwerk

Het paper stelt geen nieuwe empirische dataset voor, maar definieert een strikt meetkader (measurement framework) om dit fenomeen te bestuderen. De kernmethodologie omvat:

Definitie van FSC: Een code-sample $s$ vertoont FSC als en slechts als het functioneel correct is ($FCR(s)=1$) maar veiligheidsfalen vertoont ($SSR(s)=0$).
FSC-rate (De Metriek): In plaats van het totale aantal kwetsbaarheden te meten over alle gegenereerde code, definieert het paper de FSC-rate als de prevalentie van veiligheidsfalen binnen de subset van functioneel correcte outputs:
$FSC\text{-}rate(S) = \frac{| \{s \in S : FCR(s) = 1 \land SSR(s) = 0\} |}{| \{s \in S : FCR(s) = 1\} |}$
Deze conditionele noemer is cruciaal omdat hij het risico van "oververtrouwen" isoleert. Als een model veel functioneel correcte code produceert die toch onveilig is, zal de FSC-rate hoog zijn, zelfs als de algehele kwetsbaarheidsrate laag is.
Validatie-Stack: Om FSC te claimen, moet er een gelaagde validatie zijn:
1. Functionele correctie via taak-specifieke orakels (niet alleen stijl).
2. Veiligheidsvalidatie via een combinatie van statische analyse, dynamische tests en handmatige adjudicatie.
3. Voor FSC-hard (zie hieronder) is dynamische bewijslast (een werkende exploit-paad) noodzakelijk, omdat statische tools hierin falen.

3. Drie Ecosysteem-Visie

Het paper stelt voor om FSC te bestuderen binnen drie verschillende taak-ecosystemen, aangezien de oorzaken van valse zekerheid per context verschillen:

Algemeen Programmeren: Standaard algoritmische problemen zonder expliciete veiligheidscontext. Hier ontstaan FSC-vallen vaak doordat latente kwetsbaarheden worden gemaskeerd door taakcorrectheid.
Implementatie-contexttaken (Deployment-Context Tasks): Taken die omgaan met geheimen, autorisatie, routing en configuratie. Hier kan code functioneel werken in een testomgeving maar falen onder realistische implementatie- of bedreigingsaannames.
Expliciete Veiligheidsprogrammering: Taken waarbij de gebruiker expliciet om validatie, cryptografie of toegangsbewaking vraagt. FSC treedt hier op als het model de veiligheidsintentie lijkt te begrijpen, maar toch een kwetsbare implementatie levert.

4. Belangrijkste Bijdragen

Het paper levert vier conceptuele bijdragen:

Conceptuele Definitie: Introduceert False Security Confidence (FSC) als een meetgericht concept voor veiligheidsfalen binnen functioneel correcte outputs.
Formalisatie van FSC-rate: Definieert een conditionele metriek die veiligheidsfouten normaliseert op basis van functioneel succes, in plaats van op alle generaties. Dit onderscheidt het van bestaande gezamenlijke metrieken zoals SAFE.
Drie-Ecosysteem Model: Biedt een gestructureerde manier om te analyseren hoe FSC zich manifesteert in verschillende ontwikkelingscontexten.
FSC-hard: Definieert een verfijnde laag binnen FSC: gevallen waarin statische analyzers de kwetsbaarheid missen, maar de kwetsbaarheid dynamisch toch uitbuitbaar is. Dit is het meest gevaarlijke en misleidende deel van het probleem.

5. Resultaten en Uitkomsten

Geen Empirische Data: Dit paper is een "framework statement" en bevat geen kwantitatieve resultaten, benchmark-scores of leaderboards.
Doel: Het doel is het vaststellen van terminologie, meetgrenzen en onderzoeksontwerpen voor toekomstige grootschalige evaluaties.
Positionering: Het paper positioneert FSC als complementair aan bestaand werk (zoals SAFE en CWEval). Waar SAFE kijkt naar de totale prestatie van een methode, kijkt FSC specifiek naar het risico van oververtrouwen binnen wat eruitziet als succes.

6. Betekenis en Impact

De betekenis van dit paper ligt in het verschuiven van de meetlens in de beveiliging van AI-codegeneratie:

Van Exploitatie naar Prevalentie: In plaats van alleen te kijken naar hoe aanvallen kwetsbaarheden kunnen induceren, richt FSC zich op hoe vaak kwetsbaarheden optreden in normale, niet-aanvalsgerichte taken.
Gevaar van Stille Falen: De introductie van FSC-hard benadrukt dat de grootste dreiging niet de code is die door statische tools wordt opgepikt, maar de code die functioneel werkt en door tools als veilig wordt gemarkeerd (of geen waarschuwingen geeft).
Richting voor Benchmarking: Het paper legt de basis voor toekomstige benchmarks die niet alleen kijken of code "werkt", maar specifiek meten hoe vaak code "werkt" terwijl deze onveilig is, en hoe vaak deze onveiligheid door bestaande tools wordt gemist.

Kortom, dit paper waarschuwt dat functioneel succes een vals veiligheidsnet kan zijn, en biedt de methodologische tools om dit risico kwantificeerbaar te maken voor de toekomstige evaluatie van LLM's.