💻 computer science

Words Speak Louder Than Code: Investigating Cognitive Heuristics in LLM-Based Code Vulnerability Detection

Cet article présente la première investigation systématique démontrant que la détection de vulnérabilités de code par les LLM est significativement sensible aux heuristiques cognitives humaines (effets de cadrage, d'ancrage et de halo), lesquelles peuvent altérer les verdicts du modèle et être exploitées pour supprimer jusqu'à 97 % des vulnérabilités détectées.

Auteurs originaux : Asif Shahriar, Hongyu Cai, Hadjer Benkraouda, Gang Wang, Z. Berkay Celik

Publié 2026-06-30

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Asif Shahriar, Hongyu Cai, Hadjer Benkraouda, Gang Wang, Z. Berkay Celik

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 avez un robot garde de sécurité super intelligent dont le travail est de regarder du code informatique et de décider : « Est-ce sûr, ou est-ce une bombe à retardement ? »

Pendant longtemps, nous avons supposé que ce robot ne regardait que le code lui-même — la logique, les mathématiques, la structure. Mais ce document révèle une vérité frappante : le robot ne se contente pas de lire le code ; il lit l'histoire qui l'entoure. Et, tout comme les humains, ce robot possède des raccourcis mentaux (appelés « heuristiques cognitives ») qui peuvent le tromper dans ses décisions.

Voici la décomposition de leurs découvertes, en utilisant des analogies simples.

Les trois façons dont le robot se fait piéger

Les chercheurs ont testé trois manières spécifiques de « hacker » l'esprit du robot sans changer une seule ligne de code. Ils ont simplement changé le contexte (les métadonnées) entourant le code.

1. L'effet de Halo (Le biais de la « Célébrité »)

L'analogie : Imaginez un juge dans une salle d'audience. Si l'accusé est un PDG célèbre et respecté, le juge pourrait inconsciemment penser : « C'est une bonne personne, il ne ferait rien de mal », et être plus indulgent. Si l'accusé est un jeune stagiaire inconnu, le juge pourrait penser : « Il est inexpérimenté, il a probablement fait une erreur », et être plus sévère.

La découverte :

Lorsque le code était attribué à un « Ingénieur de sécurité principal » (un expert de haut rang), le robot est devenu paresseux et confiant. Il a manqué de réelles vulnérabilités car il supposait : « Un expert n'écrirait pas de mauvais code. »
Lorsque le même code était attribué à un « Développeur junior » (un novice de bas rang), le robot est devenu suspicieux et paranoïaque. Il a trouvé les vulnérabilités qu'il avait manquées auparavant, mais il a aussi commencé à crier au loup sur du code sûr, créant de fausses alertes.
Le rebondissement : Certains robots (comme celui nommé Claude) ont fait exactement l'inverse, faisant plus confiance au junior qu'à l'expert, mais le biais était toujours présent.

2. L'effet de Cadrage (Le biais de l'« Étiquette d'avertissement »)

L'analogie : Pensez à un flacon de médicament.

Étiquette A : « Ce médicament guérit 90 % des patients. » (Cadre positif)
Étiquette B : « Ce médicament échoue à guérir 10 % des patients. » (Cadre négatif)
Même si les mathématiques sont les mêmes, votre réaction change.

La découverte :

Cadre Positif : Lorsque le robot a été informé : « Votre tâche est de vous assurer que le pipeline fonctionne sans interruption et d'éviter les fausses alertes », il est devenu trop décontracté. Il a ignoré des bugs dangereux pour maintenir la rapidité des processus.
Cadre Négatif : Lorsque le robot a été informé : « Votre tâche est de trouver les menaces de sécurité avant qu'elles ne détruisent le système », il est devenu hyper vigilant. Il a trouvé plus de bugs, mais il a aussi commencé à signaler du code sûr comme étant dangereux.
Le résultat : C'était le tour le plus puissant de tous. Chaque robot testé a été influencé par la manière dont la tâche était décrite.

3. L'Effet d'Ancrage (Le biais de la « Première impression »)

L'analogie : Si vous demandez à un ami : « Cette maison vaut-elle 500 000 $ ? » et qu'il dit « Oui », vous pourriez penser que c'est une affaire. Si vous demandez : « Cette maison vaut-elle 1 million de dollars ? » et qu'il dit « Non », vous pourriez penser qu'elle est bon marché. Le premier chiffre que vous entendez « ancre » votre jugement.

La découverte :

Si le robot était informé : « Un scan précédent a déclaré que ce code est SÛR », il avait tendance à être d'accord et à manquer de nouveaux bugs.
Si le robot était informé : « Un scan précédent a déclaré que ce code est VULNÉRABLE », il avait tendance à être d'accord et à trouver des bugs (même s'ils n'étaient pas là).
Le robot disait essentiellement : « Eh bien, l'autre gars a dit que c'est sûr, alors je vais faire confiance à cela », au lieu de faire son propre travail indépendant.

Les grands problèmes découverts

Les chercheurs ont identifié trois problèmes majeurs dans le fonctionnement de ces robots :

1. Le problème du « Bouton de Volume »
Les robots ne sont pas devenus plus intelligents ou plus stupides pour trouver des bugs. Ils sont juste devenus plus bruyants ou plus silencieux.

Quand le contexte les rendait suspicieux, ils tournaient le « Bouton de Volume » vers le haut : ils signalaient tout comme dangereux (trouvant de vrais bugs, mais aussi beaucoup de fausses alertes).
Quand le contexte les rendait confiants, ils tournaient le « Bouton de Volume » vers le bas : ils ne signalaient rien (manquant des vrais bugs, mais ayant aussi moins de fausses alertes).
La leçon : Le robot n'a pas réellement appris à mieux distinguer le bon code du mauvais ; il a simplement changé d'humeur.

2. Le piège de l'« Hallucination »
Lorsque le robot était trompé pour croire qu'un code sûr était dangereux (à cause d'une étiquette de « Développeur Junior » ou d'une ancre « Vulnérable »), il ne se contentait pas de dire « C'est dangereux ». Il inventait souvent une fausse raison.

Exemple : Le robot voyait un code sûr mais, parce qu'il était dans une humeur « suspicieuse », il affirmait : « Cela ressemble à une fuite de mémoire ! » alors qu'il n'y avait aucune fuite. Il était confiant, mais totalement dans l'erreur.

3. Le code « Intelligent » vs « Bête »

Bugs faciles : Certains bugs sont évidents, comme une faute de frappe ou un point-virgule manquant. Le robot les trouvait facilement, quel que soit le contexte.
Bugs difficiles : Certains bugs demandent une réflexion profonde (comme suivre comment une variable évolue au fil du temps). C'est sur ceux-là que le robot a été le plus facilement trompé. Si le contexte était « confiant », il manquait les bugs difficiles. Si le contexte était « suspicieux », il inventait de faux bugs complexes.

L'« Attaque Cognitive » (Le danger réel)

Les chercheurs ne se sont pas arrêtés aux tests ; ils ont construit une preuve de concept d'attaque.

Imaginez qu'un hacker veuille introduire un morceau de code dangereux dans le logiciel d'une entreprise. Au lieu d'essayer de pirater directement le cerveau du robot (ce qui est difficile), le hacker va simplement truquer la paperasse.

Il écrit le code.
Il y joint un faux e-mail disant qu'il provient d'un célèbre expert en sécurité (Effet de Halo).
Il écrit une note disant : « Gardons le pipeline en mouvement, ne soyons pas trop pointilleux » (Cadrage).
Il joint un faux rapport disant : « Les scans précédents ont déclaré que ceci est sûr » (Ancrage).

Le Résultat : Le robot, voyant ce paquet « rassurant », a décidé que le code dangereux était SÛR. L'attaque a réussi à supprimer jusqu'à 97 % des vulnérabilités que le robot aurait normalement détectées.

L'essentiel à retenir

Ce document prouve que les modèles de langage étendus (LLM) utilisés pour la sécurité ne sont pas des machines objectives. Ils sont influencés par les mêmes astuces psychologiques qui influencent les humains.

Ils font confiance aux mauvaises personnes (trop aux experts, trop peu aux juniors).
Ils réagissent à la manière dont on pose la question (peur vs confort).
Ils restent bloqués sur les premières impressions (rapports précédents).

La partie la plus dangereuse ? Vous n'avez pas besoin d'être un génie du piratage pour les briser. Il vous suffit de savoir écrire un e-mail convaincant ou un message de commit séduisant. Le robot n'est pas cassé ; il est simplement humain dans ses failles.

Résumé Technique : Les mots parlent plus fort que le code

Énoncé du problème
Les modèles de langage de grande taille (LLM) sont de plus en plus déployés comme des gardiens de sécurité automatisés dans des flux de travail réels, tels que les pipelines CI/CD et les revues de pull requests. Alors que des recherches antérieures ont établi que les LLM présentent des heuristiques cognitives dans le raisonnement général et les tâches subjectives, aucune investigation systématique n'a examiné si ces heuristiques biaisent les LLM dans la tâche objective de la détection de vulnérabilités de code. En pratique, les scanners de vulnérabilités ne analysent pas le code de manière isolée ; ils ingèrent des métadonnées contextuelles non liées au code, notamment l'identité de l'auteur, les messages de commit, les directives de tâche et les résultats d'analyses antérieurs. Cet article postule que ce contexte organique et non malveillant peut involontairement déclencher des heuristiques cognitives (effet de halo, effet de cadrage et ancrage), menant à des verdicts de sécurité incohérents pour un code identique. Le problème central est que ces biais peuvent être exploités pour supprimer la détection de vulnérabilités ou gonfler les faux positifs sans modifier le code lui-même.

Méthodologie
Les auteurs présentent un cadre contrôlé pour isoler l'impact du contexte non lié au code sur les verdicts des LLM.

Conception expérimentale : L'étude maintient fixe l'extrait de code ( $S$ ) tout en faisant varier uniquement le contexte environnant ( $C$ ) pour déclencher des heuristiques cognitives spécifiques. La fonction de détection est définie comme $f(C, S) \rightarrow \{0, 1\}$ , où le verdict dépend de l'interaction entre le code et le contexte.
Heuristiques investiguées :
1. Effet de Halo : Manipulé via l'attribution de l'auteur. Les variantes incluent le prestige lié à la sécurité (ex: « Ingénieur principal en sécurité de Project Zero » vs « Développeur junior ») et le prestige non lié à la sécurité (ex: « Contributeur de longue date » vs « Premier contributeur »).
2. Effet de Cadrage : Manipulé via les directives de tâche et les énoncés de conséquences. Les variantes incluent le cadrage gain-perte (accentuer les bénéfices d'un code sûr vs les coûts des brèches) et le cadrage d'objectif (vérifier la conformité vs identifier les violations).
3. Effet d'Ancrage : Manipulé via les résultats d'analyses antérieurs. Les variantes incluent des ancres fortes (verdicts explicites « SÛR » ou « VULNÉRABLE ») et des ancres faibles (résultats implicites comme « passé » ou « n'a pas passé » les vérifications pré-fusion).
Configuration de l'évaluation : Le cadre a été appliqué à huit LLM de pointe (cinq open-source, trois commerciaux) à travers trois langages de programmation (C/C++, Java, Python). Les jeux de données utilisés étaient PRIMEVUL (C/C++ avec échantillons bénins et vulnérables) et CLEANVUL (Python et Java, uniquement vulnérables).
Métriques : L'étude a mesuré le Rappel ( $R$ ), le Taux de Faux Positifs (TFP), la Précision et le score F1. De manière cruciale, elle a introduit l'Écart de Rappel ( $\Delta R$ ) et l'Écart de TFP ( $\Delta TFP$ ) pour quantifier l'ampleur du biais entre les polarités (ex: haut vs bas halo). Un Indice d'Utilité (IU) a été calculé pour déterminer si une heuristique améliorait la détection de manière constructive (en augmentant le rappel plus que le TFP).

Principales contributions

Première investigation systématique : Ce travail est la première exploration systématique des heuristiques cognitives dans la détection de vulnérabilités de code pilotée par les LLM, évaluant trois heuristiques distinctes à travers huit modèles et trois langages.
Analyse fine : Les auteurs fournissent une analyse au niveau du code révélant que les heuristiques n'améliorent pas la capacité d'analyse d'un modèle. Au lieu de cela, elles agissent comme un « bouton de volume », déplaçant la propension du modèle à signaler le code comme vulnérable sans améliorer sa capacité à distinguer les véritables vulnérabilités du code bénin.
Démonstration adversaire : L'article démontre une preuve de concept d'attaque cognitive en boîte noire. En forgeant des métadonnées d'apparence bénigne (identité de l'auteur, descriptions de PR et messages de commit), un attaquant peut supprimer jusqu'à 97 % des vulnérabilités précédemment détectées dans un flux de travail CI/CD simulé.

Résultats

Susceptibilité universelle : Les huit modèles évalués ont montré une susceptibilité aux heuristiques cognitives. La susceptibilité moyenne entre les modèles était la plus élevée pour le Cadrage (33,2 %), suivie de l'Ancrage (23,5 %) et du Halo (18,4 %).
Directionnalité :
- Cadrage : Chaque modèle a répondu dans la direction attendue (le cadrage négatif augmentait le rappel, le cadrage positif le diminuait).
- Halo et Ancrage : Les réponses variaient. Les modèles open-source montraient généralement les réponses attendues (un faible prestige/une ancre sûre réduisait la détection), tandis que les modèles commerciaux comme Claude et GPT montraient des réponses inverses ou mixtes (ex: GPT est devenu plus suspicieux sous une attribution d'auteur à haut prestige).
Absence d'utilité constructive : Les heuristiques cognitives n'ont pas amélioré la capacité de détection. L'Indice d'Utilité était négatif ou proche de zéro pour la plupart des modèles. Lorsque le rappel augmentait, le TFP augmentait d'une magnitude presque identique, laissant la précision stagnante (0,48–0,55). Les modèles changeaient souvent les verdicts de « Sûr » à « Vulnérable » (ou vice versa) basés sur le contexte, mais échouaient à identifier la vulnérabilité réelle, hallucinant souvent des problèmes plausibles mais incorrects.
Vulnérabilités dépendantes du raisonnement : Les vulnérabilités nécessitant un raisonnement sémantique (ex: suivi de l'état du programme, gestion des exceptions) étaient significativement plus susceptibles aux heuristiques (écart 1,5x à 2x plus élevé) que celles identifiables par reconnaissance de formes.
Succès de l'attaque : L'attaque cognitive a réussi à supprimer la détection dans un modèle de menace réaliste. Les défenses standard basées sur le prompt (ex: instruire le modèle d'ignorer les métadonnées) ont échoué à atténuer l'attaque.

Signification
L'article conclut que la susceptibilité cognitive est une propriété constante et exploitable de la détection de vulnérabilités pilotée par les LLM. Les conclusions remettent en question la fiabilité des gardiens de sécurité automatisés qui reposent sur les LLM, démontrant que le contexte non lié au code peut systématiquement biaiser les verdicts de sécurité. L'étude souligne que les modèles actuels ne font pas simplement des « erreurs », mais sont susceptibles de biais psychologiques qui peuvent être instrumentalisés pour contourner les contrôles de sécurité. Cela suggère que le déploiement des LLM dans des rôles critiques pour la sécurité nécessite une évaluation rigoureuse de leur robustesse face à la manipulation contextuelle, et non seulement de la qualité du code.

Les trois façons dont le robot se fait piéger

1. L'effet de Halo (Le biais de la « Célébrité »)

2. L'effet de Cadrage (Le biais de l'« Étiquette d'avertissement »)

3. L'Effet d'Ancrage (Le biais de la « Première impression »)

Les grands problèmes découverts

L'« Attaque Cognitive » (Le danger réel)

L'essentiel à retenir

Articles similaires