TOSSS: a CVE-based Software Security Benchmark for Large Language Models

Dit paper introduceert TOSSS, een op CVE's gebaseerde benchmark die de veiligheid van Large Language Models evalueert door hun vermogen te meten om tussen veilige en kwetsbare codefragmenten te kiezen, waarbij geteste modellen scores tussen 0,48 en 0,89 behalen.

De kern

Stel je voor dat je een zeer slimme, digitale assistent hebt die alles kan schrijven: van e-mails tot complexe computerprogramma's. Dit zijn de LLMs (Large Language Models), de "super-intelligente" AI's waar veel bedrijven nu van dromen. Ze kunnen code schrijven alsof ze een ervaren programmeur zijn.

Maar hier zit een addertje onder het gras: Is deze AI ook veilig?

Stel je voor dat je een chef-kok hebt die fantastisch kan koken, maar soms per ongeluk giftige paddenstoelen in de soep doet. Dat is precies wat deze paper onderzoekt. De auteurs, een groep onderzoekers uit Nederland, Frankrijk en de VS, hebben een nieuwe test bedacht om te zien of deze AI's echt veilig code kunnen maken of dat ze juist gevaarlijke fouten (kwetsbaarheden) inbouwen.

Hier is de uitleg van hun onderzoek, vertaald naar alledaags taalgebruik:

1. Het probleem: De oude tests werken niet meer

Vroeger vroegen onderzoekers aan de AI: "Schrijf een programma dat een wachtwoord bewaakt." Vervolgens keken ze of het programma veilig was.
Het probleem hiermee is als het controleren van een auto door te kijken of hij misschien een band lek heeft. Het is lastig, duur en je kunt niet snel nieuwe soorten bandenproblemen toevoegen. Als er morgen een nieuw soort lek ontdekt wordt, moet je de hele test opnieuw uitvinden.

2. De oplossing: TOSSS (De "Kies de Veilige Optie"-test)

De auteurs hebben een slimme nieuwe test bedacht, genaamd TOSSS. In plaats van de AI te vragen om iets nieuks te bouwen, geven ze de AI een keuze.

De analogie:
Stel je voor dat je een huis wilt bouwen. De AI krijgt twee blauwdrukken:

• Optie A: Een huis met een deur die altijd open staat (gevaarlijk).
• Optie B: Een huis met een stevige slot op de deur (veilig).

De AI moet zeggen: "Ik kies voor A" of "Ik kies voor B".

• Als de AI consequent B kiest, is hij veilig.
• Als hij A kiest, is hij een risico.
• Als hij willekeurig kiest, is hij net zo goed als een muntje opgooien.

Dit is veel makkelijker te testen dan het bouwen van een heel huis. Je kunt duizenden van deze "blauwdrukken" (paren van veilige en onveilige code) maken en de AI erdoorheen laten lopen.

3. Waar komen de tests vandaan? (De "MegaVul"-schattenjacht)

Hoe maken ze deze tests? Ze gebruiken een enorme database met alle bekende software-fouten ter wereld, de CVE-database.
Stel je voor dat ze een schatkaart hebben van alle dieven die ooit in huizen zijn ingebroken. Ze kijken naar een inbraak (een fout), en kijken hoe de eigenaar het later heeft opgelost (de veilige code).

• De versie voor de oplossing is de "gevaarlijke" optie.
• De versie na de oplossing is de "veilige" optie.

Omdat ze dit automatisch doen met een computerprogramma, kunnen ze elke dag nieuwe inbraken toevoegen aan hun test. De test groeit dus mee met de wereld, zonder dat mensen handmatig alles hoeven te schrijven.

4. Wat hebben ze ontdekt? (De resultaten)

Ze hebben 14 verschillende AI-modellen getest (zowel die van grote tech-bedrijven als open-source modellen) op code in C/C++ en Java.

• De winnaars: Sommige AI's (zoals GLM-5 en GPT-5.4) waren heel goed. Ze kozen bijna altijd de veilige optie (een score van bijna 1,0).
• De verliezers: Andere AI's deden het slecht. Sommigen kozen zelfs vaker de gevaarlijke optie dan de veilige (een score onder de 0,5). Dat is alsof ze bewust de sleutel onder de mat leggen voor de dief.
• De verrassing: De AI's die speciaal zijn getraind om code te schrijven (zoals Codestral) deden het niet per se beter dan de algemene AI's. Soms deden ze het zelfs slechter! Het lijkt erop dat ze zo gefocust zijn op "werkend" maken, dat ze vergeten om "veilig" te maken.

De "Hint"-effect:
Toen de onderzoekers de AI's expliciet vroegen: "Kies de veiligste optie!", werden de meeste AI's beter. Maar sommige werden juist slechter! Alsof ze in paniek raakten als je ze te specifiek vraagt. Dit betekent dat we AI-assistenten misschien bewust moeten vragen om op veiligheid te letten, anders doen ze het niet vanzelf.

5. Waarom is dit belangrijk?

Vroeger was het lastig om te zeggen: "Deze AI is veilig." Nu hebben we een meetlat (TOSSS) die dat kan.

• Voor bedrijven: Ze kunnen nu kijken welke AI ze veilig kunnen gebruiken in hun systemen.
• Voor de toekomst: Omdat de test automatisch nieuwe fouten toevoegt, blijft hij altijd actueel. Het is als een alarm dat automatisch update als er een nieuw type inbraak wordt ontdekt.

Conclusie

Deze paper zegt eigenlijk: "Laat de AI niet alleen maar bouwen, laat hem ook kiezen."
Door AI's te testen op het kiezen tussen een veilige en een onveilige optie, krijgen we een eerlijk en snel beeld van hoe veilig ze zijn. En het goede nieuws? Met de juiste instructies ("Kies de veilige optie!") kunnen we de meeste AI's aanzienlijk veiliger maken.

De onderzoekers hebben hun test gratis beschikbaar gesteld, zodat iedereen het kan gebruiken. Het is een belangrijke stap om te voorkomen dat onze digitale wereld vol komt te staan met software die per ongeluk een open deur is voor hackers.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "TOSSS: a CVE-based Software Security Benchmark for Large Language Models" in het Nederlands.

Probleemstelling

Met de snelle opkomst van Large Language Models (LLMs) in softwareontwikkeling workflows, rijst de kritische vraag of deze modellen daadwerkelijk veilig code kunnen genereren. Bestaande studies tonen aan dat LLMs vaak kwetsbaarheden introduceren (bijvoorbeeld 40% van de code gegenereerd door GitHub Copilot bleek kwetsbaar).

Bestaande benchmarks voor het testen van softwareveiligheid van LLMs hebben echter belangrijke beperkingen:

1. Beperkte uitbreidbaarheid: Ze zijn vaak gebaseerd op vaste sets taken en afhankelijk van statische analyzers (zoals CodeQL). Dit maakt het moeilijk om nieuwe, recent ontdekte kwetsbaarheden of nieuwe programmeertalen snel op te nemen.
2. Gebrek aan "Ground Truth": Bij code-generatie taken is het lastig om een perfecte referentie-implementatie te hebben om de output mee te vergelijken.
3. Schalingsproblemen: Veel benchmarks vereisen handmatige validatie of complexe fuzzing, wat niet schaalbaar is.

Er is dus behoefte aan een benchmark die uitbreidbaar is, gebruikmaakt van echte kwetsbaarheidsdata, en een eenduidige meting biedt.

Methodologie: TOSSS

De auteurs introduceren TOSSS (Two-Option Secure Snippet Selection). In plaats van de LLM te vragen om code te genereren, wordt de evaluatie omgebogen naar een code-selectie taak.

• Het Principe: De LLM krijgt twee implementaties van dezelfde functie gepresenteerd: één versie is veilig (secure) en de andere bevat een kwetsbaarheid (vulnerable). De taak van het model is om te kiezen welke versie het verkiest.
• Prompting: Er worden twee scenario's getest:
  1. Hintless: De prompt vraagt alleen om een keuze zonder te verwijzen naar veiligheid.
  2. Met Hint: De prompt vraagt expliciet om de "meest veilige implementatie" te kiezen.
• Data-constructie (CVE Mining): Om de testcases te bouwen, gebruiken de auteurs de MegaVul-pipeline. Dit is een geautomatiseerd proces dat het CVE-database (Common Vulnerabilities and Exposures) scant. Het haalt paren code op: de versie voor een beveiligingsfix (kwetsbaar) en de versie na de fix (veilig). Dit garandeert dat de dataset gebaseerd is op echte, geverifieerde kwetsbaarheden.
• Score: De veiligheidsscore loopt van 0 tot 1.
  • 1,0: Het model kiest altijd de veilige code.
  • 0,5: Het model kiest willekeurig.
  • < 0,5: Het model heeft een bias naar kwetsbare code.

Belangrijkste Bijdragen

1. Nieuwe Benchmark (TOSSS): Een schaalbaar en uitbreidbaar framework dat LLMs test op hun vermogen om veilige code te onderscheiden van kwetsbare code.
2. CVE-gebaseerde Data: In plaats van handmatig samengestelde datasets, wordt gebruik gemaakt van een geautomatiseerde pipeline die direct koppelt aan de CVE-database. Dit maakt het mogelijk om nieuwe kwetsbaarheden automatisch toe te voegen naarmate ze worden ontdekt.
3. Interpreteerbare Metriek: De score is direct interpreteerbaar als een waarschijnlijkheid dat het model de veilige optie kiest, in tegenstelling tot complexe metrieken zoals pass@k bij generatie-taken.
4. Open Source: De volledige benchmark en code zijn open-source beschikbaar gesteld om reproduceerbaarheid te waarborgen.

Experimentele Resultaten

De auteurs hebben TOSSS uitgevoerd op 14 populaire LLMs (zowel open-source als gesloten, waaronder GPT-5, Claude, LLaMA, Gemini, Mistral) met code in C/C++ en Java.

• Algemene Prestaties: De scores varieerden sterk, van 0,48 (Mistral Large 2512, wat dicht bij willekeurige keuze ligt) tot 0,89 (GLM-5). Dit toont aan dat er een groot verschil is in veiligheidsbewustzijn tussen modellen.
• Invloed van Hints:
  • Het expliciet vragen om veiligheid ("pick the most secure implementation") verbeterde de scores voor de meeste modellen (gemiddeld +0,02 tot +0,03).
  • Uitzondering: Codestral 2508 (een model specifiek geoptimaliseerd voor coderen) presteerde slechter wanneer de hint werd gegeven. Dit suggereert dat specifieke instructies soms conflicteren met de interne logica van code-generatie modellen.
• Coderingsspecialisten vs. Algemene Modellen: Modellen die specifiek zijn getraind als "coder assistants" (zoals Qwen3 Coder en Codestral) presteerden verrassend slecht in de "hintless" setting. Dit suggereert dat optimalisatie voor functionaliteit en vloeiheid niet automatisch leidt tot een beter vermogen om veiligheidsrisico's te herkennen.
• Taalverschillen: De prestaties waren vergelijkbaar voor C/C++ en Java, wat aangeeft dat de benchmark algemene veiligheidsredenering meet en niet alleen taal-specifieke patronen.

Betekenis en Conclusie

Het paper toont aan dat LLMs in staat zijn om veilige code te onderscheiden van kwetsbare code, maar dat dit vermogen sterk varieert per model en vaak niet volledig wordt benut zonder expliciete instructies.

De belangrijkste implicaties zijn:

• Complementaire Evaluatie: TOSSS vult bestaande benchmarks aan. Het is een efficiëntere manier om de fundamentele veiligheidskennis van een model te testen dan het genereren van code en deze vervolgens te analyseren.
• Training en Prompting: De resultaten suggereren dat het toevoegen van expliciete veiligheidsinstructies in prompts (system prompts) essentieel kan zijn om de veiligheidsprestaties van assistenten te verbeteren.
• Toekomstbestendigheid: Omdat de benchmark gebaseerd is op CVE-data, blijft deze up-to-date met de evoluerende landschap van cyberdreigingen zonder dat er handmatige ingrepen nodig zijn.

Kortom, TOSSS biedt een robuust, schaalbaar en transparant instrument voor ontwikkelaars en organisaties om de veiligheidskwaliteit van LLMs te monitoren en te verbeteren.