💻 computer science

Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs

Cette étude évalue l'efficacité et le coût de quatre grands modèles de langage modernes pour détecter les vulnérabilités interprocédurales en C, C++ et Python, démontrant que l'inclusion du contexte des fonctions appelantes et appelées améliore la détection, avec Gemini 3 Flash offrant le meilleur compromis coût-performance pour le C et Claude Haiku 4.5 fournissant les explications les plus fiables.

Auteurs originaux : Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

Publié 2026-04-10

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🕵️‍♂️ Le Grand Défi : Trouver les failles dans le code

Imaginez que le code informatique est une immense ville remplie de bâtiments (les programmes). Parfois, il y a des portes dérobées ou des fenêtres cassées : ce sont les failles de sécurité (vulnérabilités). Si un voleur les trouve, il peut voler des données ou prendre le contrôle de la ville.

Pour trouver ces failles, les chercheurs ont fait appel à des super-détecteurs intelligents : des Intelligences Artificielles (les LLMs, comme ChatGPT ou Gemini).

🧩 Le Problème : Regarder une seule pièce ou toute la maison ?

Jusqu'à présent, la plupart des détecteurs regardaient une seule pièce d'un bâtiment à la fois pour voir si elle était dangereuse.

L'ancienne méthode : "Cette pièce a-t-elle une porte cassée ?"
La nouvelle hypothèse : "Et si la porte cassée était dans le couloir, mais que c'est la pièce d'à côté qui l'a laissée ouverte ?"

Les chercheurs se sont demandé : Est-ce que donner plus de contexte au détecteur (en lui montrant les pièces voisines, celles qui appellent la pièce cible ou celles qu'elle appelle) l'aide à mieux trouver les voleurs ?

C'est comme demander à un détective :

"Regarde juste cette pièce." (Contexte seul)
"Regarde cette pièce et celle où le voleur est entré." (Contexte + appelant)
"Regarde cette pièce et celle où le voleur va sortir." (Contexte + appelé)

🧪 L'Expérience : 4 Détecteurs, 3 Langues, 509 Cas

Les chercheurs ont testé 4 détecteurs modernes (Claude Haiku, GPT-4.1 Mini, GPT-5 Mini, Gemini 3 Flash) sur 509 cas réels de failles dans trois langages de programmation différents (C, C++, Python), qui sont comme trois quartiers différents de la ville avec des règles différentes.

Ils ont mesuré deux choses :

L'efficacité : Le détective trouve-t-il le voleur ?
Le prix : Combien coûte l'enquête (en argent et en temps de calcul) ?

📉 Les Résultats Surprenants : "Moins, c'est parfois mieux !"

C'est ici que ça devient intéressant. On pensait que "plus d'informations = meilleur détective". Faux !

Le choc : Pour certains détecteurs (surtout les modèles "GPT" de OpenAI), donner trop de contexte a rendu le détective plus bête. C'est comme si on lui donnait un dossier de 1000 pages alors qu'il suffisait de lire 10 pages. Il s'est perdu dans les détails inutiles et a raté le coupable.
- Exemple : Pour le langage C, donner le contexte des pièces voisines a fait chuter la performance de certains détecteurs de 25 %.
Les champions : Deux détecteurs (Claude Haiku et Gemini 3 Flash) sont restés calmes et efficaces, qu'on leur donne une seule pièce ou tout le quartier. Ils savent filtrer l'information inutile.

💰 Le Prix de l'Enquête

Donner plus de contexte coûte cher.

Ajouter les pièces voisines a presque doublé la facture (plus de pages à lire = plus de tokens = plus d'argent).
Le gagnant du rapport qualité/prix : Gemini 3 Flash. Il est très bon (presque parfait) pour le langage C et coûte moins cher que les autres pour un résultat similaire.
Le champion de l'explication : Claude Haiku 4.5. Il ne se contente pas de dire "Il y a un voleur", il explique exactement comment le voleur est entré et comment le chasser, avec une précision incroyable (93,6 % des cas).

🇫🇷 En Résumé : Ce qu'il faut retenir

Ne noyez pas vos détecteurs : Pour certaines IA, donner trop de contexte (les fonctions voisines) les embrouille et les rend moins performantes. Parfois, il vaut mieux se concentrer sur le cœur du problème.
Tout dépend du langage : Ce qui marche pour le langage C ne marche pas forcément pour Python. Il faut adapter sa stratégie.
Le prix compte : Ajouter du contexte coûte cher sans toujours améliorer le résultat. Gemini 3 Flash est le meilleur compromis pour trouver les failles rapidement et pas cher.
L'explication est cruciale : Un bon détective doit savoir pourquoi il a trouvé la faille. Claude Haiku est le meilleur pour rédiger un rapport clair et utile pour les développeurs.

La leçon finale : Pour construire un outil de sécurité parfait, il ne faut pas juste jeter toutes les informations à l'IA. Il faut choisir le bon détective (le bon modèle) et lui donner juste la quantité d'information nécessaire, selon la langue du code.

1. Problématique et Contexte

La détection automatisée des vulnérabilités logicielles est devenue un enjeu critique pour la sécurité des systèmes modernes. Bien que les Modèles de Langage (LLM) soient de plus en plus utilisés pour cette tâche, la littérature existante présente deux limites majeures :

Portée limitée : La plupart des études se concentrent sur la détection de vulnérabilités au sein de fonctions isolées, négligeant les dépendances interprocédurales (les flux de données et de contrôle traversant plusieurs fonctions). Or, de nombreuses vulnérabilités (débordements de tampons, utilisation après libération, injections) ne sont détectables qu'en analysant l'interaction entre un appelant (caller) et une fonction appelée (callee).
Manque de généralisation et d'analyse économique : Les études se limitent souvent à un seul langage de programmation et ignorent les coûts d'inférence ainsi que la qualité des explications générées par les modèles, pourtant essentiels pour l'adoption par les développeurs.

L'article vise à combler ces lacunes en évaluant l'efficacité, le coût et la qualité explicative de LLMs modernes dans la détection de vulnérabilités interprocédurales à travers plusieurs langages (C, C++, Python).

2. Méthodologie

Les auteurs ont mené une étude empirique rigoureuse basée sur les éléments suivants :

Dataset : Utilisation du jeu de données ReposVul, filtré pour extraire 509 vulnérabilités interprocédurales réelles issues de projets open-source (CVE).
Modèles évalués : Quatre LLMs modernes de différents fournisseurs, sélectionnés pour leur rapport coût-performance et leur support de contexte long :
- Claude Haiku 4.5 (Anthropic)
- GPT-4.1 Mini et GPT-5 Mini (OpenAI)
- Gemini 3 Flash (Google)
Configuration expérimentale : Pour chaque fonction vulnérable, trois configurations de contexte ont été testées :
1. Code Only (CO) : Code de la fonction cible uniquement.
2. Code + Callees (CC) : Fonction cible + code des fonctions qu'elle appelle.
3. Code + Callers (CK) : Fonction cible + code des fonctions qui l'appellent.
Langages : C, C++ et Python.
Métriques :
- Efficacité : Précision, Rappel (Rappel = Précision ici car l'ensemble ne contient que des vulnérabilités), et F1-score.
- Coût : Calculé en USD basé sur la consommation de tokens (prix par million de tokens).
- Qualité explicative : Évaluation manuelle sur un échantillon stratifié (986 réponses) selon deux dimensions : Correction (exactitude du type et de l'emplacement) et Exhaustivité (présence de vecteurs d'attaque et suggestions de correction).
Analyse statistique : Utilisation du test de McNemar pour comparer les performances entre les configurations de contexte, avec correction de Holm-Bonferroni.

3. Résultats Clés

A. Impact du Contexte Interprocédural (RQ1 & RQ2)

Contre-intuitif : L'ajout de contexte interprocédural (appelants ou appelés) n'améliore pas systématiquement la détection. Dans de nombreux cas, il dégrade les performances.
Dépendance au modèle :
- Les modèles GPT-4.1 Mini et GPT-5 Mini subissent une chute significative de précision en C lorsqu'on ajoute du contexte (jusqu'à -25 points de pourcentage pour GPT-4.1 Mini en configuration Code + Callees). Cela suggère que le contexte supplémentaire introduit du "bruit" qui perturbe le raisonnement de ces modèles.
- Claude Haiku 4.5 et Gemini 3 Flash montrent une grande robustesse : leurs performances restent stables (voire légèrement meilleures) quelle que soit la configuration de contexte, indiquant une meilleure capacité à filtrer l'information pertinente.
Dépendance au langage : L'effet négatif du contexte est plus marqué en C (gestion manuelle de la mémoire, couplage fort) qu'en Python (plus autonome). Les résultats pour le C++ sont limités par la taille de l'échantillon.

B. Efficience et Coût (RQ3)

Coût exponentiel : L'ajout de contexte interprocédural double presque la consommation de tokens (et donc le coût d'inférence) sans apporter de gains proportionnels en précision.
Meilleur compromis : Gemini 3 Flash offre le meilleur rapport coût-performance, en particulier pour le C, atteignant un F1-score $\ge$ 0,978 pour un coût estimé de 0,50 $à 0,58$ par configuration.
Claude Haiku 4.5 est le plus performant en termes de détection pure et d'explications, mais son coût est plus de deux fois supérieur à celui de Gemini 3 Flash pour des gains marginaux en détection.

C. Qualité des Explications (RQ4)

Corrélation détection/explication : La qualité de l'explication est fortement corrélée à la qualité de la détection.
Leader : Claude Haiku 4.5 domine largement, obtenant un score parfait (2/2 sur correction et exhaustivité) dans 93,6 % des cas évalués.
Faiblesses des GPT : Les modèles GPT (Mini) présentent des taux d'erreurs fondamentales (score 0) cinq fois plus élevés (6-7 %) que Haiku ou Gemini (< 1,2 %).
Gemini 3 Flash est très bon sur la correction mais parfois moins exhaustif dans ses suggestions de réparation.

4. Contributions Principales

Évaluation empirique du contexte interprocédural : Démontre que "plus de contexte" n'est pas toujours synonyme de "meilleure détection" et que cela dépend fortement de l'architecture du modèle.
Analyse multi-langages et multi-modèles : Première étude comparant systématiquement l'impact du contexte sur C, C++ et Python avec des LLMs de dernière génération.
Analyse coût-performance : Introduction d'une métrique économique concrète pour la détection de vulnérabilités, montrant que l'ajout de contexte est souvent économiquement inefficace.
Évaluation qualitative des explications : Fournit des données sur la capacité des LLMs à justifier leurs décisions de sécurité, un aspect souvent négligé.

5. Signification et Implications Pratiques

Conception d'outils de sécurité : Les outils d'analyse assistés par IA ne doivent pas systématiquement inclure tout le graphe d'appels. Le niveau de contexte doit être calibré en fonction du modèle utilisé (ex: éviter le contexte étendu pour les modèles GPT Mini en C) et du langage cible.
Choix du modèle :
- Pour un rapport coût-efficacité optimal : Gemini 3 Flash.
- Pour la qualité des explications et l'audit de sécurité : Claude Haiku 4.5.
- Pour un coût minimal avec une précision acceptable : GPT-4.1 Mini (mais avec risque accru d'erreurs).
Hypothèse remise en question : L'étude contredit l'hypothèse courante selon laquelle l'augmentation du contexte d'entrée améliore toujours les performances des LLMs en sécurité, révélant au contraire un risque de dégradation dû au bruit informationnel.

En conclusion, cette recherche fournit des directives cruciales pour le déploiement pratique de LLMs dans les pipelines de développement sécurisé, en soulignant l'importance de l'alignement entre le modèle choisi, la granularité du contexte fourni et les contraintes budgétaires.