Persistent Human Feedback, LLMs, and Static Analyzers for Secure Code Generation and Vulnerability Detection

Résumé Technique : Feedback Humain Persistant, LLM et Analyseurs Statiques pour la Génération de Code Sécurisé et la Détection de Vulnérabilités

Énoncé du Problème
L'article traite de la dépendance croissante aux grands modèles de langage (LLM) pour la génération de code sécurisé et la détection de vulnérabilités, en soulignant une lacune critique dans les méthodologies d'évaluation actuelles. Bien que les LLM soient de plus en plus utilisés dans le développement logiciel, ils génèrent fréquemment du code non sécurisé même lorsqu'ils sont explicitement instruits de ne pas le faire. La littérature existante évalue principalement ces modèles en utilisant des outils d'analyse statique automatisés (par exemple, CodeQL, Semgrep) comme seule vérité de terrain (ground truth). Les auteurs soutiennent que cette approche est défectueuse car les analyseurs statiques présentent des taux de faux positifs élevés et échouent souvent à s'aligner sur le jugement des experts humains concernant les vulnérabilités de sécurité réelles. De plus, les cadres actuels manquent de mécanismes pour stocker et réutiliser de manière persistante le feedback des experts, limitant la capacité des LLM à apprendre des corrections passées.

Méthodologie
L'étude emploie une méthodologie à deux volets : une revue exhaustive de la littérature et une étude de validation empirique.

1. Revue de la Littérature : Les auteurs ont recensé 2025 publications issues de conférences de premier plan en génie logiciel (A/A*) pour caractériser les tendances de recherche actuelles. Ils ont analysé les benchmarks, les langages de programmation cibles, les familles de modèles et les outils d'évaluation utilisés dans les études de génération de code sécurisé et de détection de vulnérabilités.
2. Validation Empirique :
   • Construction du Jeu de Données : En utilisant la technique de prompting de type Recursive Critiques Improvement (RCI) avec GPT-4o, les auteurs ont généré 1 080 échantillons de code basés sur 108 tâches uniques mappées sur le CWE Top 25.
   • Création de la Vérité de Terrain : Deux réviseurs formés (un doctorant et un étudiant en Master), sous la supervision d'un professeur, ont inspecté manuellement les échantillons pour les étiquter comme vulnérables ou sécurisés par rapport à leur CWE cible spécifique. Les désaccords ont été résolus par discussion ou arbitrage d'expert, atteignant un accord inter-évaluateur élevé (kappa de Cohen $\kappa = 0,94$).
   • Comparaison d'Outils : La vérité de terrain validée manuellement a été comparée aux sorties de deux outils d'analyse statique largement utilisés, CodeQL et Semgrep.
   • Proposition de Cadre : Sur la base de ces résultats, les auteurs proposent un cadre conceptuel intégrant le feedback humain dans un pipeline de génération augmentée par récupération (RAG).

Résultats Clés
L'étude empirique a révélé des divergences significatives entre les outils automatisés et les experts humains :

• Vérité de Terrain : 61 % des échantillons générés étaient réellement sécurisés, tandis que 39 % contenaient des vulnérabilités.
• Performance des Outils : Semgrep a classé 60 % des échantillons comme sécurisés et CodeQL a classé 80 % comme sécurisés. Bien que le taux global de Semgrep paraisse proche du jugement humain, l'analyse par échantillon a montré des désaccords substantiels.
• Métriques de Précision : Seuls 65 % des rapports de Semgrep et 61 % des rapports de CodeQL correspondaient correctement aux étiquettes de la vérité de terrain.
• Couverture CWE : Les deux outils ont échoué à détecter les CWE cibles dans une fraction substantielle des cas de vérité de terrain et ont fréquemment signalé des découvertes pour des CWE non ciblés (dont la validité restait inconnue dans cette étude).
• Auto-critique : L'étude a observé que les LLM fournissant des auto-critiques « spécifiques » (feedback ciblé et actionnable) produisaient un code plus sécurisé (64 % de sécurisé) par rapport aux critiques « générales » (56 % de sécurisé).

Cadre Proposé : Feedback Humain Persistant
Pour répondre aux limites des outils statiques et à la nature transitoire des boucles de feedback actuelles, les auteurs proposent un cadre conceptuel (illustré par la Figure 3) qui intègre un agent Human-in-the-Loop (HIL) dans un pipeline RAG dynamique. Le cadre se compose de quatre agents :

1. Agent de Prompt : Orchestre la génération de code en récupérant des conseils de sécurité pertinents à partir d'un RAG à double source (Feedback Humain et Connaissance de Vulnérabilité Externe) pour affiner le prompt du développeur.
2. Agent de Sécurité : Évalue le code généré à l'aide d'analyseurs statiques et de LLM, produisant des rapports lisibles par machine et par l'humain.
3. Agent Human-in-the-Loop (HIL) : Agit comme le décideur final. Les experts examinent les rapports de l'Agent de Sécurité. En cas de désaccord, le feedback de l'expert est stocké de manière persistante dans le RAG.
   • Pondération de la Confiance : Le système attribue des poids de confiance dynamiques au feedback en fonction du consensus des réviseurs et du succès empirique historique (en utilisant une moyenne mobile exponentielle).
   • Double Révision : Pour prévenir l'empoisonnement des données, un nouveau feedback nécessite l'approbation de deux réviseurs distincts avant d'entrer dans le pool de récupération actif.
4. RAG à Double Source : Un service de connaissance partagé qui donne la priorité au feedback validé par l'humain (HF) sur la connaissance externe générale (EVK) en utilisant une fonction de score composite qui pénalise les contradictions entre les conseils généraux et le feedback de l'expert.

Signification et Revendications
L'article affirme que s'appuyer uniquement sur les outils d'analyse statique pour évaluer le code généré par les LLM est peu fiable et pose des risques pour la validité de la recherche en sécurité. Les auteurs soutiennent que le feedback des experts est non seulement nécessaire pour des instances individuelles, mais peut aussi se généraliser à des cas futurs similaires. Par conséquent, le cadre proposé vise à permettre aux LLM de réutiliser dynamiquement le feedback humain antérieur, améliorant ainsi à la fois la génération de code sécurisé et la détection de vulnérabilités. L'étude conclut que la communauté du génie logiciel doit dépasser l'évaluation uniquement automatisée et intégrer des boucles de feedback persistantes, pilotées par des experts, pour garantir la fiabilité des LLM dans des contextes critiques pour la sécurité.

Limites (Menaces à la Validité)
Les auteurs reconnaissent plusieurs limites :

• Validité de Construction : La revue de la littérature a été restreinte aux publications de 2025 dans les conférences de génie logiciel, ce qui pourrait omettre des modèles issus de conférences spécifiques à la sécurité (ex: USENIX Security, CCS).
• Validité Interne : Les étiquettes de vérité de terrain reposent sur une évaluation manuelle, laquelle est sujette aux biais humains malgré un accord inter-évaluateur élevé.
• Validité Externe : Les expériences se sont concentrées sur le code Python généré par GPT-4o via le prompting RCI. Les résultats peuvent ne pas se généraliser à d'autres langages (particulièrement les langages de bas niveau comme le C/C++), d'autres domaines, ou d'autres LLM et outils d'analyse statique.