🤖 AI

An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors

Cette étude empirique démontre que les grands modèles de langage, en particulier ceux optimisés pour le raisonnement comme DeepSeek-R1, surpassent nettement les outils d'analyse statique de pointe dans l'examen de code de sécurité, tout en identifiant que les stratégies d'ingénierie de prompt, la complexité du code et la taille des fichiers sont des facteurs critiques influençant leur précision de détection et la qualité de leurs réponses.

Auteurs originaux : Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

Publié 2026-05-12

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jiaxin Yu, Peng Liang, Yujia Fu, Amjed Tahir, Mojtaba Shahin, Chong Wang, Yangxiao Cai

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

Imaginez que vous êtes l'éditeur d'une bibliothèque massive et chaotique où des milliers de personnes écrivent constamment de nouveaux chapitres pour une histoire géante et partagée. Votre travail consiste à trouver les trous de scénario dangereux, les rebondissements qui pourraient faire s'effondrer toute l'histoire, ou les pages qui pourraient permettre à un voleur de s'infiltrer et de voler les livres. C'est l'Examen de sécurité du code.

Traditionnellement, vous aviez deux façons de faire cela :

L'Éditeur Humain : Un expert fatigué qui lit chaque mot. Il est bon pour comprendre le contexte, mais lent et coûteux.
Le Correcteur Orthographique Automatisé : Un robot qui scanne les mots connus pour être mauvais. Il est rapide, mais il crie souvent « ERREUR ! » alors qu'il n'y a rien de mal (fausses alertes) et manque des astuces subtiles et ingénieuses.

Ce document demande : Un nouveau type de « Super-Lecteur » (les Modèles de Langage à Grande Échelle ou LLM) peut-il faire un meilleur travail que les anciens correcteurs orthographiques ?

Voici ce que les chercheurs ont découvert, expliqué par de simples analogies :

1. Les Concurrents : Qui s'est présenté à la bibliothèque ?

Les chercheurs ont fait venir sept « Super-Lecteurs » (LLM) différents. Certains sont polyvalents (bons pour écrire des poèmes et des e-mails), et l'un est un modèle « Optimisé pour le Raisonnement » (entraîné spécifiquement à réfléchir étape par étape comme un détective). Ils ont également fait venir les anciens « Correcteurs Orthographiques Automatisés » (outils d'analyse statique) pour voir qui gagnerait.

Le Résultat : Les Super-Lecteurs ont écrasé les anciens correcteurs orthographiques. Le détective « Optimisé pour le Raisonnement » (appelé DeepSeek-R1) était le champion clair, suivi de près par GPT-4 (celui que vous connaissez peut-être via ChatGPT). Les anciens outils ont été laissés dans la poussière, principalement parce qu'ils se perdent dans des intrigues complexes (comme les conditions de course dans le code) qui nécessitent de comprendre comment différentes parties de l'histoire interagissent au fil du temps.

2. Le Prompt Magique : La manière de demander compte

Tout comme poser une question à un bibliothécaire, la manière dont vous demandez au Super-Lecteur compte. Les chercheurs ont essayé cinq façons différentes de demander :

La Demande de Base : « Trouvez les bogues. »
La Demande Contextuelle : « Voici le message de commit (la note laissée par l'auteur sur ce qu'ils ont changé). Réfléchissez étape par étape. »
La Demande avec Fiches Mémo : « Voici une liste de types de crimes connus (liste CWE). Cherchez-les. »

Le Gagnant :

Pour DeepSeek-R1, la meilleure méthode consistait à lui donner la note de l'auteur (message de commit) et à lui dire de « réfléchir étape par étape » (Chaîne de Pensée). C'est comme donner au détective le journal du suspect et lui demander de parcourir la scène du crime de manière logique.
Pour GPT-4, la meilleure méthode consistait à lui remettre la « Fiche Mémo » (la liste des crimes connus). Il fonctionne mieux lorsqu'il a une liste de contrôle spécifique à suivre.

3. Les Défauts : Même les Super-Lecteurs font des erreurs

Les chercheurs n'ont pas seulement regardé qui trouvait les bogues ; ils ont examiné comment les Super-Lecteurs les rapportaient. Ils ont découvert deux défauts de personnalité distincts :

GPT-4 (Le Poète Vague) : Il trouve souvent le bon problème, mais le décrit de manière brumeuse et vague. Il pourrait dire : « Il y a un risque de sécurité quelque part dans ce fichier », sans pointer la ligne exacte. Il ignore parfois les instructions, comme oublier de dire « Aucun bogue trouvé » lorsqu'il n'y en a pas.
DeepSeek-R1 (Le Vérificateur de Faits Trop Confiant) : Celui-ci est très précis. Il pointe des numéros de ligne exacts et des extraits de code. Cependant, il hallucine parfois. Il pourrait pointer avec assurance la ligne 42 et dire : « Cette ligne est dangereuse », alors que la ligne 42 est en fait sûre. C'est comme un détective si désireux de résoudre l'affaire qu'il invente des preuves qui n'existent pas.

4. Le Problème de « L'Aiguille dans la Botte de Foin »

Les chercheurs ont découvert que ces Super-Lecteurs ont du mal lorsque l'histoire devient trop longue.

Fichiers Courts : Ils sont excellents pour trouver des bogues dans des fichiers de code courts et concis.
Fichiers Longs : À mesure que le code s'allonge (plus de « tokens »), les Super-Lecteurs se distraitent. Ils manquent les petits détails dangereux enfouis au milieu d'un fichier massif. C'est comme essayer de trouver une seule faute de frappe dans un roman de 500 pages ; vos yeux se vitrifient et vous la manquez.

5. Le Paradoxe de la Complexité

Voici un rebondissement surprenant :

Habituellement, nous pensons que le code complexe est plus difficile à vérifier.
Mais pour DeepSeek-R1, un code plus complexe l'aide en fait à trouver certains types de bogues (sauf ceux liés à la mémoire).
Pourquoi ? Les chercheurs suggèrent que le code complexe contient souvent plus de « indices » et de structure au sein du fichier lui-même. Le Super-Lecteur peut utiliser ces indices internes pour raisonner sur le problème. Un code simple et désordonné offre moins d'indices, rendant plus difficile pour l'IA de comprendre ce qui se passe.

La Conclusion

Le document conclut que les Super-Lecteurs IA sont de nouveaux outils puissants qui sont actuellement meilleurs que les scanners automatisés traditionnels pour trouver des failles de sécurité dans le code. Cependant, ils ne sont pas encore des remplacements parfaits pour les éditeurs humains.

DeepSeek-R1 est le meilleur pour réfléchir aux problèmes, mais il doit être surveillé pour qu'il n'invente pas de faits.
GPT-4 est bon pour suivre des listes de contrôle, mais peut être trop vague.
La Stratégie : La meilleure approche n'est pas de remplacer les humains, mais d'utiliser ces outils IA comme un premier passage. Laissez l'IA scanner d'abord les fichiers courts et complexes, puis faites vérifier le travail de l'IA par des éditeurs humains, en particulier lorsque l'IA devient trop confiante ou trop vague.

Le document ne prétend pas que ces outils sont prêts à gérer la bibliothèque seuls, ni qu'ils sont parfaits. Il montre simplement qu'ils sont un nouvel assistant très prometteur qui nécessite une manipulation prudente.

Titre : Une perspective sur l'examen de code de sécurité avec les LLM : capacités, obstacles et facteurs influents

Énoncé du problème
L'examen de code de sécurité est un processus critique mais laborieux, essentiel pour prévenir les violations de données et les pertes financières. Bien que les organisations intègrent de plus en plus l'analyse de sécurité dans l'examen de code, les outils automatisés existants (analyse statique, dynamique ou hybride) souffrent d'une mauvaise généralisation, d'un taux élevé de faux positifs et d'une granularité de détection grossière. De plus, les approches basées sur les données, utilisant l'apprentissage automatique ou l'apprentissage profond traditionnels, manquent souvent de robustesse en raison de la rareté des ensembles de données d'entraînement réalistes, ce qui se traduit par de mauvaises performances sur des projets réels. Bien que les modèles de langage de grande taille (LLM) aient montré des promesses dans diverses tâches d'ingénierie logicielle, leurs capacités spécifiques, leurs limites et les facteurs influençant leurs performances dans le contexte fin de l'examen de code de sécurité restent largement inexplorés.

Méthodologie
Les auteurs ont mené une étude empirique pour évaluer le potentiel des LLM dans la détection de défauts de sécurité lors de l'examen de code. L'étude a utilisé un ensemble de données manuellement curaté de 534 fichiers de code (258 Python, 276 C/C++) dérivés de quatre projets open source (OpenStack Nova/Neutron et Qt Base/Creator), contenant 614 commentaires d'examen liés à la sécurité.

Modèles évalués : Sept LLM ont été testés, incluant des modèles propriétaires (GPT-4, GPT-4 Turbo, Gemini Pro), des modèles open source (Llama 2 7B, Llama 2 70B) et un modèle optimisé pour le raisonnement (DeepSeek-R1).
Ingénierie des invites : Cinq modèles d'invite distincts ont été conçus sur la base des meilleures pratiques et des stratégies antérieures :
1. Invite de base ( $P_b$ ) : Instruction directe d'examiner le code.
2. Informations sur le projet ( $P_r$ ) : Ajout du contexte du nom du projet.
3. Instruction CWE générale ( $P_c$ ) : Instruction d'utiliser le CWE comme référence.
4. Instruction CWE spécifique ( $P_{cid}$ ) : Fourniture d'une liste de CWE de haut niveau.
5. Chaîne de pensée ( $P_{cot}$ ) : Une invite en deux étapes exigeant que le modèle génère un contexte de code à partir d'un message de commit avant d'analyser les défauts. Une version « garde-fou » ( $P_{cot-guardrail}$ ) a également été testée pour isoler l'impact du contexte généré.
Métriques d'évaluation : Les réponses ont été étiquetées manuellement en quatre catégories : Instrumentale (type de défaut, localisation et description précis), Utile (partiellement précise), Trompeuse (échec de détection ou faux négatifs) et Incertitude. Les métriques comprenaient le score I, le score IH et le score M. La cohérence a été mesurée via l'entropie des réponses sur trois runs expérimentaux.
Analyse : L'étude a comparé les performances des LLM à celles des outils d'analyse statique de pointe (par exemple, CodeQL, Bandit, CppCheck). Pour les modèles les plus performants, une analyse linguistique a identifié des problèmes de qualité (par exemple, hallucinations, imprécision). Enfin, des modèles de régression à liens cumulatifs ont été construits pour analyser l'influence de 11 facteurs (par exemple, nombre de jetons, complexité du code, type de défaut) sur la performance.

Contributions clés

Évaluation fine : Fourniture d'une évaluation complète des LLM populaires dans l'examen de code de sécurité, allant au-delà de la classification binaire pour évaluer la localisation des défauts, la description et les suggestions de correction.
Analyse du non-déterminisme : Mesure de l'impact du non-déterminisme des LLM sur la cohérence des résultats de l'examen de code de sécurité.
Quantification des problèmes de qualité : Identification et quantification de problèmes de qualité spécifiques, y compris les hallucinations (factuelles et de fidélité), dans les réponses des modèles les plus performants.
Analyse de l'influence des facteurs : Réalisation de la première analyse de régression pour valider statistiquement comment des attributs spécifiques du code et du projet influencent les performances des LLM dans ce domaine.

Résultats

Performance par rapport aux bases de référence : Les LLM ont nettement surpassé les outils d'analyse statique de pointe dans l'examen de code de sécurité. Parmi les LLM, le modèle optimisé pour le raisonnement (DeepSeek-R1) a dépassé les modèles à usage général.
Meilleurs performeurs : DeepSeek-R1 a atteint la meilleure performance globale, suivi de GPT-4 (via la plateforme ChatGPT).
- Invites optimales : DeepSeek-R1 a obtenu les meilleurs résultats avec une invite combinant le message de commit et l'orientation par chaîne de pensée (CoT) ( $P_{cot-guardrail}$ ). GPT-4 (ChatGPT) a obtenu les meilleurs résultats avec une invite contenant une liste spécifique de CWE ( $P_{cid}$ ).
Problèmes de qualité :
- GPT-4 (ChatGPT) : A fréquemment produit des expressions vagues et a eu des difficultés à suivre les instructions (par exemple, numéros de ligne manquants), bien qu'il ait commis moins d'erreurs factuelles concernant les détails du code.
- DeepSeek-R1 : Plus enclin à générer des détails de code inexacts (par exemple, numéros de ligne ou noms de fonctions incorrects) et a présenté un taux plus élevé d'hallucinations de « fait incorrect », malgré de meilleures capacités de suivi des instructions.
Facteurs influents :
- Nombre de jetons : Les LLM étaient plus aptes à identifier les défauts dans les fichiers contenant moins de jetons ; les performances ont généralement diminué à mesure que le nombre de jetons augmentait.
- Annotations : La présence d'annotations liées à la sécurité dans le code a amélioré les capacités de détection.
- Complexité : Une complexité de code plus élevée a été corrélée à des capacités de détection améliorées pour DeepSeek-R1 pour certains types de défauts (à l'exclusion de ceux liés à la mémoire), contrairement à l'hypothèse selon laquelle la complexité entrave toujours la détection.
- Cohérence : Les modèles avec des capacités de détection plus élevées (DeepSeek-R1, GPT-4 ChatGPT) ont présenté une cohérence plus faible (entropie plus élevée) entre les runs par rapport aux modèles moins performants.

Signification et affirmations
L'article affirme que, bien que les LLM actuels ne soient pas encore un remplacement pour les examinateurs humains, ils servent d'outils auxiliaires puissants qui surpassent nettement les outils d'analyse statique traditionnels dans la détection de défauts de sécurité. L'étude met en évidence que l'efficacité des LLM dépend fortement de l'ingénierie des invites (spécifiquement l'inclusion de messages de commit, de CoT ou de listes de CWE) et des caractéristiques spécifiques du code examiné (nombre de jetons, complexité, annotations).

Les auteurs soulignent que le non-déterminisme des LLM est une arme à double tranchant : les modèles capables d'un raisonnement plus profond (et donc d'une meilleure détection) tendent à produire des sorties plus incohérentes. Ils concluent qu'une stratégie d'examen à plusieurs niveaux est nécessaire, où les LLM gèrent les examens initiaux de code de faible difficulté (moins de jetons) tandis que les experts humains se concentrent sur le code de haute difficulté et valident les découvertes des LLM. L'étude souligne également la nécessité de travaux futurs pour remédier aux hallucinations concernant les détails du code et améliorer la stabilité des sorties des LLM sans sacrifier la sensibilité de détection.