FR
De fausses assurances de sécurité peuvent tromper les modèles d’audit de code
Trusting the Tool: Asymmetric Deference of LLM Vulnerability Auditors to Static-Analysis Evidence · arXiv:2610.32876
En termes simples
Quand des modèles de langage recherchent des failles dans du code C/C++, ils peuvent recevoir des notes produites par un programme d’analyse. Cet article propose une méthode contrôlée pour vérifier si les modèles confrontent ces notes au code, surtout lorsqu’une note affirme qu’une vérification de sécurité existe ou qu’elle manque.
Pour l’un des modèles testés, les fausses notes affirmant qu’une vérification existait lui ont fait manquer davantage de fonctions vulnérables. Les fausses alertes signalant une vérification manquante n’ont pas réduit sa précision. Une étape de vérification distincte a aidé ce modèle lors d’un test ultérieur.
La recherche
Quand un modèle de langage vérifie du code à l’aide d’un analyseur, confronte-t-il les affirmations de l’analyseur au code ? La réponse compte, car une note disant qu’une vérification de sécurité existe peut susciter une réaction différente d’une note disant qu’elle manque.
L’étude teste si cette différence apparaît lorsque les affirmations portent sur les mêmes opérations du code.
Les auteurs comparent des audits de modèles de langage avec des notes exactes et fabriquées d’un analyseur pour déterminer si ces modèles examinent différemment les affirmations de sécurité et de danger.
Les auteurs ont comparé les audits des mêmes fonctions C/C++ vulnérables ou corrigées, en faisant varier les notes de l’analyseur. Pour deepseek-chat, de fausses affirmations selon lesquelles une vérification existait ont fait baisser la précision sur les fonctions vulnérables de 0.75 avec des notes exactes et pertinentes à 0.64 ; de fausses alertes signalant une vérification manquante ont fait monter la précision sur les fonctions corrigées de 0.67 à 0.79.
Ces comparaisons appariées ne changeaient que la véracité des notes portant sur les mêmes opérations.
Comme les modèles peuvent avoir des tendances initiales différentes à signaler du code, les auteurs ont aussi mesuré le déplacement des verdicts vers chaque fausse affirmation par rapport aux notes exactes. Dans une réplication sur sept nouveaux modèles, le déplacement moyen favorisait les fausses assurances.
Ces résultats étayent l’existence d’une asymétrie dans la réaction des modèles testés aux deux types d’affirmations.
Ces résultats proviennent d’audits isolés de fonctions C/C++ courtes, avec des éléments de preuve construits par l’analyseur des auteurs.
L’étape de vérification proposée a amélioré les résultats de deepseek-chat lors d’un test défini à l’avance, mais le gain plus faible observé pour qwen-plus n’était pas statistiquement significatif.
Ce que montrent les preuves
- La question des éléments fournis
L’article présente une méthode contrôlée pour étudier comment les modèles de langage utilisent des éléments d’analyse statique lorsqu’ils recherchent des failles dans des fonctions C/C++.
La question est de savoir si les modèles confrontent au code les affirmations sur ses vérifications, et s’ils examinent différemment celles qui disent qu’une vérification existe et celles qui disent qu’elle manque. La méthode isole la réaction aux éléments fournis au lieu de mesurer uniquement la détection des vulnérabilités.
- Créer des notes vérifiables
Pour connaître la véracité de chaque note, les auteurs ont créé un analyseur qui répertorie les opérations sensibles et les conditions réunies sur chaque chemin menant à ces opérations, ainsi que les problèmes que la fonction n’écarte pas.
Ils ont associé des fonctions vulnérables à leurs versions corrigées, puis fait varier les notes présentées aux modèles. Il était possible de vérifier les affirmations fausses à partir de la fonction ; le modèle ne voyait pas le correctif. Les auteurs ont ainsi pu comparer des notes fausses et exactes portant sur les mêmes opérations.
- La véracité a changé l’effet
Dans les configurations DeepSeek flash rapportées, les notes exactes de l’analyseur ont peu changé la précision de façon mesurable : afficher toutes ces notes l’a modifiée de +0.02 pour chacune, sans différence statistiquement significative.
La comparaison la plus directe gardait la fonction et la pertinence de la note constantes, tout en changeant sa véracité. Pour deepseek-chat, les fausses affirmations selon lesquelles une vérification existait ont réduit la précision sur les fonctions vulnérables, tandis que les fausses alertes signalant une vérification manquante ne l’ont pas réduite sur les fonctions corrigées.
- Comparer les déplacements de verdict
La précision seule peut refléter la tendance préalable d’un modèle à signaler du code comme vulnérable. Les auteurs ont également mesuré si les fausses notes déplaçaient les verdicts vers leur propre affirmation, par rapport à des notes exactes portant sur les mêmes opérations.
Lors d’une réplication enregistrée en interne sur sept nouveaux modèles, l’asymétrie moyenne était positive : les fausses assurances ont davantage rapproché les verdicts de « sûr » que les fausses alertes ne les ont rapprochés de « vulnérable ». L’ampleur variait selon les modèles.
- Tester une étape de vérification
Les auteurs interprètent ces résultats comme une différence dans le niveau de vérification : l’affirmation qu’une vérification manque peut inciter à la chercher, tandis que celle qui dit qu’elle existe peut être acceptée sans contrôle.
Lors d’un test défini à l’avance, un appel distinct a vérifié les notes et présenté les affirmations réfutées ; cette étape a amélioré la précision de deepseek-chat sous de fausses assurances, sans modifier sa précision sous des notes exactes et pertinentes. Le gain était plus faible et non statistiquement significatif pour qwen-plus.
Détails
- Auteurs de l’article original
- ZhiHong Liu, Shuyao Gao
- Soumis à arXiv
- Licence
- arXiv non-exclusive