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

Ce papier présente TOSSS, un nouveau benchmark basé sur la base de données CVE permettant d'évaluer la capacité des modèles de langage à distinguer le code sécurisé du code vulnérable, révélant des scores de sécurité variables parmi 14 modèles testés.

L'essentiel

🕵️‍♂️ TOSSS : Le grand test de sécurité des "Robots Écrivains"

Imaginez que vous avez engagé un assistant très intelligent, capable d'écrire du code informatique (le langage des ordinateurs) aussi bien qu'un humain. C'est ce qu'on appelle un LLM (Modèle de Langage à Grande Échelle), comme ceux qui propulsent ChatGPT ou d'autres outils d'IA.

Mais voici le problème : si ce robot écrit un code avec une faille de sécurité, c'est comme si vous laissiez la porte de votre maison grande ouverte pour les voleurs. Les entreprises s'inquiètent : "Est-ce que mon robot est un bon gardien ou un mauvais serrurier ?"

C'est là qu'intervient l'article que nous allons explorer. Les auteurs ont créé un nouveau test, baptisé TOSSS, pour mesurer la capacité de ces robots à repérer les codes sûrs.

1. Le problème des anciens tests : "Faire le devoir"

Avant TOSSS, pour tester ces robots, on leur donnait un exercice : "Écris-moi un programme qui gère les mots de passe."
Ensuite, des experts humains ou des logiciels spécialisés (des "détecteurs de fumée") regardaient le résultat pour voir s'il y avait des trous.

Le souci ? C'est comme demander à un élève de faire un devoir de maths, puis de corriger soi-même les erreurs. C'est long, difficile à mettre à jour quand de nouvelles erreurs apparaissent, et les "détecteurs" ne voient pas tout. Si un nouveau type de faille est découvert demain, les anciens tests ne le savent pas encore.

2. La solution TOSSS : "Le jeu du choix"

Au lieu de demander au robot de créer quelque chose, les auteurs de TOSSS lui disent : "Regarde, voici deux versions d'une même fonction. L'une est sûre, l'autre est dangereuse. Laquelle choisis-tu ?"

C'est comme un jeu de "Vrai ou Faux" ou de "Lequel est le plus sûr ?".

• Le scénario : On montre au robot deux portes.
  • La porte A est solide, avec une bonne serrure.
  • La porte B a un trou dans le bois et la serrure est cassée.
• La question : Le robot doit pointer la porte A.
• Le résultat : Si le robot choisit la bonne porte 100 % du temps, il a un score de 1 (parfait). S'il choisit au hasard, il a un score de 0,5. S'il choisit souvent la mauvaise porte, c'est mauvais signe.

3. Pourquoi c'est génial ? (L'analogie de la bibliothèque)

Pour créer ce jeu, les auteurs n'ont pas inventé des scénarios de leur tête. Ils ont utilisé une bibliothèque géante de failles réelles (la base de données CVE).

Imaginez que chaque fois qu'un hacker trouve une faille dans un logiciel réel, un "rapport de police" est écrit. TOSSS va chercher ces rapports, regarde comment les ingénieurs ont réparé la faille (avant/après), et crée automatiquement des paires de questions pour le robot.

• Avantage 1 : La mise à jour automatique. Dès qu'une nouvelle faille est découverte dans le monde réel, TOSSS peut l'ajouter au jeu presque instantanément. C'est un jeu qui se met à jour tout seul !
• Avantage 2 : La clarté. Pas besoin de deviner si le code généré est bon. Le robot doit juste dire "A" ou "B". C'est simple, rapide et sans ambiguïté.

4. Ce qu'ils ont découvert (Les résultats)

Les chercheurs ont testé 14 robots célèbres (comme GPT, Claude, LLaMA, etc.) avec ce jeu. Voici ce qu'ils ont vu :

• Certains sont de bons gardiens : Des robots comme GLM-5 ou GPT-5.4 ont choisi la bonne porte plus de 85 % du temps. Ils comprennent bien la sécurité.
• D'autres sont un peu perdus : Certains robots ont choisi au hasard (50 %) ou même pire, ils ont souvent choisi la porte cassée !
• Le secret du "Mot Magique" : Quand les chercheurs ont ajouté une petite phrase dans la question du robot : "Choisis l'option la plus SÉCURISÉE", la plupart des robots sont devenus beaucoup plus performants.
  • Analogie : C'est comme si vous demandiez à un cuisinier de faire un gâteau. S'il ne sait pas que vous voulez un gâteau sans sucre, il en mettra. Mais si vous lui dites explicitement "Sans sucre !", il s'adapte. Les robots ont besoin qu'on leur rappelle qu'ils doivent penser à la sécurité.
• Le paradoxe des experts : Étonnamment, certains robots spécialisés uniquement dans la programmation (les "experts en code") n'étaient pas les meilleurs pour choisir le code sécurisé. Ils sont très forts pour écrire vite, mais pas toujours pour vérifier la sécurité.

5. Pourquoi c'est important pour nous ?

Aujourd'hui, beaucoup d'entreprises utilisent ces robots pour écrire du code. Si nous ne savons pas si ces robots savent choisir la "bonne porte", nous risquons de construire des logiciels fragiles.

TOSSS est comme un nouveau permis de conduire pour les robots. Au lieu de regarder s'ils savent conduire vite (générer du code), on regarde s'ils savent respecter les panneaux de sécurité.

Les auteurs ont rendu ce test gratuit et accessible à tous (sur GitHub) pour que tout le monde puisse vérifier la sécurité de ses propres robots.

En résumé

L'article nous dit : "Arrêtons de demander aux robots de tout inventer. Donnons-leur un choix simple entre le bien et le mal, et voyons s'ils savent distinguer la sécurité. C'est plus facile à tester, plus facile à mettre à jour, et ça nous donne une vraie idée de leur fiabilité."

C'est une étape cruciale pour s'assurer que l'intelligence artificielle ne devient pas notre pire ennemi en matière de cybersécurité.

Résumé technique

Voici un résumé technique détaillé de l'article "TOSSS: a CVE-based Software Security Benchmark for Large Language Models", rédigé en français.

1. Problématique

L'adoption croissante des Modèles de Langage (LLM) dans les workflows de développement logiciel soulève une question critique : les LLM sont-ils compétents en matière de sécurité logicielle ? Bien que les LLM soient utilisés pour générer du code, des études antérieures ont montré qu'ils produisent souvent du code vulnérable (par exemple, 40 % du code généré par GitHub Copilot contenait des failles de sécurité).

Les benchmarks de sécurité existants pour les LLM souffrent de limitations majeures :

• Manque d'extensibilité : Ils reposent souvent sur des ensembles de tâches fixes et des analyseurs statiques (comme CodeQL) dont la couverture est limitée aux vulnérabilités qu'ils savent détecter. Il est difficile d'y intégrer de nouvelles vulnérabilités ou de nouveaux langages.
• Absence de vérité terrain explicite : Contrairement à l'évaluation classique en ML, la génération de code produit des artefacts complexes difficiles à comparer à une référence unique, obligeant à l'utilisation d'outils approximatifs.
• Coût de maintenance : La création de cas de test manuels ou l'adaptation d'outils d'analyse pour chaque nouvelle faille n'est pas scalable.

Il existe donc un besoin urgent d'un benchmark extensible, scalable et basé sur des données réelles pour évaluer objectivement la capacité des LLM à identifier et sélectionner du code sécurisé.

2. Méthodologie : TOSSS

Les auteurs proposent TOSSS (Two-Option Secure Snippet Selection), un nouveau benchmark qui reformule l'évaluation de la sécurité non pas comme une tâche de génération de code, mais comme une tâche de sélection de code.

Principe de fonctionnement :

1. Format de la tâche : Le modèle reçoit deux versions d'une même fonction : l'une est vulnérable, l'autre est sécurisée (la version corrigée).
2. Instruction : Le modèle doit choisir la version qu'il préfère (A ou B).
3. Scénarios d'évaluation :
   • Sans indice (Hintless) : La consigne est neutre ("Choisissez la version A ou B"). Cela teste la capacité intrinsèque du modèle à distinguer la sécurité sans guidance explicite.
   • Avec indice (With Hint) : La consigne mentionne explicitement la sécurité ("Choisissez l'implémentation la plus sûre"). Cela évalue si le modèle peut mobiliser ses connaissances de sécurité lorsqu'on lui demande de le faire.
4. Métrique : Le score de sécurité est la proportion de fois où le modèle sélectionne la version sécurisée. Un score de 1 indique une sélection parfaite, 0,5 un choix aléatoire, et < 0,5 un biais vers le code vulnérable.

Construction des données (Pipeline) :
Pour garantir l'extensibilité et la pertinence des données, TOSSS s'appuie sur la base de données CVE (Common Vulnerabilities and Exposures) via l'outil MegaVul.

• Le pipeline extrait automatiquement les paires de code "avant/après" correction de commits liés à des CVE.
• Cela permet de construire des jeux de données massifs et évolutifs couvrant des vulnérabilités réelles et variées, sans intervention manuelle lourde.
• L'étude initiale se concentre sur les langages C/C++ et Java.

3. Contributions Clés

• Nouvelle méthodologie d'évaluation : Passage d'une tâche de génération (complexe à évaluer) à une tâche de sélection binaire (facile à évaluer, robuste aux variations de format de sortie).
• Extensibilité basée sur les CVE : Le benchmark peut intégrer automatiquement de nouvelles vulnérabilités dès qu'elles sont corrigées et répertoriées dans les dépôts de code, contrairement aux benchmarks statiques actuels.
• Interprétabilité des scores : Le score TOSSS a une interprétation probabiliste directe (probabilité de choisir le code sûr), ce qui le rend plus intuitif pour les praticiens que des métriques comme le pass@k.
• Benchmark Open Source : Les auteurs publient le code et les données pour faciliter la reproductibilité et l'adoption par la communauté.

4. Résultats Expérimentaux

Les auteurs ont évalué 14 modèles (open-source et propriétaires, incluant GPT-5, Claude, LLaMA, Gemini, etc.) sur 500 fonctions C/C++ et 500 fonctions Java.

Principales observations :

• Performance globale : Les scores varient considérablement, allant de 0,48 (Mistral Large 2512, proche du hasard) à 0,89 (GLM-5). Cela montre une hétérogénéité importante dans les compétences en sécurité des modèles.
• Impact des indices (Hints) :
  • Pour la plupart des modèles, demander explicitement de choisir le code le plus sûr améliore les performances (gain moyen de +0,02 à +0,03).
  • Certains modèles faibles bénéficient davantage de l'indice (ex: Mistral Large +0,068).
  • Cas notable : Le modèle spécialisé en codage Codestral 2508 voit ses performances baisser lorsqu'on lui donne l'indice de sécurité, suggérant que l'instruction explicite peut interférer avec son processus de sélection optimisé pour la génération fonctionnelle.
• Spécialisation Codage vs Sécurité : Les modèles explicitement conçus pour le codage (Qwen3 Coder, Codestral) ne se classent pas nécessairement en tête du classement sécurité. Cela indique que l'optimisation pour la génération de code fonctionnel ne garantit pas la maîtrise de la sécurité.
• Langages : Les performances sont comparables entre C/C++ et Java, suggérant que le benchmark mesure un raisonnement de sécurité général plutôt que des motifs spécifiques à un langage.
• Évolution des modèles : Au sein d'une même famille (ex: Anthropic Claude), les versions plus récentes et plus grandes montrent systématiquement de meilleures performances en sécurité.

5. Signification et Implications

• Complémentarité : TOSSS ne vise pas à remplacer les benchmarks de génération de code, mais à les compléter. Il offre une évaluation plus fiable et scalable des compétences de sécurité de base.
• Prérequis à la génération : La capacité à identifier le code sûr est vue comme une condition nécessaire (prérequis) pour pouvoir générer du code sûr. Si un modèle ne peut pas distinguer une faille parmi deux options, il est peu probable qu'il génère du code sécurisé de lui-même.
• Amélioration des pratiques : Les résultats suggèrent que les assistants de codage basés sur LLM devraient intégrer systématiquement des instructions explicites de sécurité dans leurs prompts pour débloquer les capacités de sécurité latentes des modèles.
• Avenir : La méthodologie TOSSS ouvre la voie à une surveillance continue de la sécurité des LLM face à l'évolution rapide des menaces, en s'appuyant sur le flux naturel des correctifs de vulnérabilités (CVE).

En conclusion, TOSSS fournit un cadre robuste, évolutif et interprétable pour mesurer la maturité sécuritaire des LLM, révélant que si la plupart des modèles modernes possèdent une certaine conscience de la sécurité, celle-ci reste inégale et souvent sous-exploitée sans guidance explicite.