Résumé Technique : Du Verdict au Diagnostic : Revue de Sécurité Attribuable des Pull Requests

1. Définition du Problème : Le fossé Verdict–Diagnostic (VD)

Les examinateurs de code automatisés actuels sont principalement évalués sur leur capacité à émettre un verdict de « blocage » pour les Pull Requests (PR) malveillantes. Cependant, l'article identifie une faille critique dans ce paradigme d'évaluation : un examinateur peut bloquer correctement une PR pour la mauvaise raison. Un blocage peut être déclenché par un problème sans rapport (par exemple, une erreur de formatage ou un avertissement non critique) plutôt que par la vulnérabilité spécifique qui rend la PR dangereuse.

Cette divergence est appelée le fossé Verdict–Diagnostic (VD).

• Verdict : La décision d'approuver ou de bloquer une PR.
• Diagnostic : L'identification spécifique de la vulnérabilité et les preuves qui la soutiennent.
• Le Fossé : Un verdict de blocage correct associé à un diagnostic incorrect ou non étayé. Dans de tels cas, les efforts de remédiation sont mal dirigés, laissant la vulnérabilité réelle non traitée.

L'article soutient que les benchmarks et les métriques d'évaluation existants ne parviennent pas à distinguer un système qui se contente de « bloquer » d'un système qui « diagnostique » correctement le défaut de sécurité sous-jacent. De plus, de nombreuses vulnérabilités (particulièrement les défauts de type « absence » où une garde requise est manquante) nécessitent des preuves provenant de parties inchangées du dépôt, ce que l'analyse basée uniquement sur le diff néglige souvent.

2. Méthodologie

2.1 MALPR-BENCH : Un Benchmark Fondé sur les Mécanismes

Pour mesurer le fossé VD, les auteurs introduisent MALPR-BENCH, un benchmark conçu pour évaluer séparément trois dimensions distinctes :

1. Exactitude du Verdict (V) : Le système a-t-il bloqué la PR ?
2. Identification de la Vulnérabilité Cible (I) : Le système a-t-il correctement identifié le mécanisme de vulnérabilité spécifique ?
3. Validation des Preuves (E) : Le système a-t-il fondé son diagnostic sur des faits concrets et auditables du dépôt (emplacements de code, fichiers inchangés, etc.) ?

Construction :

• Échelle : 89 PR malveillantes et 50 contrôles bénins répartis sur 44 dépôts et huit familles de langages.
• Sources :
  • Historique Miné : Récupération de correctifs incomplets issus des historiques de projets.
  • Dérivé d'Avis de Sécurité : Construction d'états malveillants à partir d'avis de sécurité publics (Pool A : correctif incomplet ; Pool B : inversion de l'application des règles).
  • Découverte en Conditions Réelles : Vulnérabilités précédemment non divulguées trouvées par l'outil des auteurs.
• Vérité de Terrain (Ground Truth) : Chaque cas inclut une « rubrique figée » spécifiant la vulnérabilité cible, la chaîne de preuves requise et les descriptions acceptées. Cela permet une notation précise pour déterminer si une revue est « attribuable » (c'est-à-dire $A = V \land I \land E$).
• Classification des Défauts : Les cas sont classés comme de type Présent (le comportement dangereux est visible dans le diff) ou de type Absence (une application de sécurité requise est manquante). Les emplacements de preuves sont classés de L0 (diff uniquement) à L2b (correspondance sémantique dans des fichiers non liés).

2.2 PRGUARD : Un Examinateur de Sécurité Attribuable

Pour remédier au fossé VD, les auteurs proposent PRGUARD, un système qui sépare l'identification de la vulnérabilité de la validation des preuves. Contraãment aux modèles de bout en bout qui passent directement du diff au verdict, PRGUARD opère via un pipeline par étapes :

• Étape 0 (Collecte Structurelle) : Collecte déterministe du contexte structurel (appelants, appelés, imports) autour du code modifié avant toute raisonnement du modèle.
• Étape 1 (Caractérisation du Changement) : Le modèle décrit le comportement lié à la sécurité du changement sans encore proposer une vulnérabilité spécifique.
• Étapes 2 & 2.5 (Acquisition de Preuves) :
  • Chemin 1 (Dirigé par la Connaissance) : Utilise une Base de Connaissances de Mécanismes (KB) dérivée de cas de développement pour récupérer des preuves spécifiques au dépôt via des relations typées (ex: SIBLING-ENDPOINT).
  • Chemin 2 (Dirigé par le Code) : Construit une liste de travail de chemins du dépôt basée sur la structure du code modifié, indépendamment de la KB.
• Étape 3 (Construction de Candidats) : Formule des candidats de vulnérabilités concrètes basées sur les preuves collectées.
• Étape 4 (Validation des Preuves) : Une invocation de modèle distincte teste les candidats contre les preuves du dépôt. Elle vérifie les prémisses critiques de sécurité (contrôle de l'attaquant, atteignabilité, gardes manquantes). Les candidats sont marqués comme VALIDÉS, REMIS EN CAUSE (DOWNGRADED) ou REJETÉS.
• Étape 5 (Synthèse de la Revue) : Une politique déterministe mappe les résultats de validation vers un verdict (Bloquer, Commenter, Approuver) et synthétise une revue qui explique les découvertes validées avec des emplacements de code spécifiques.

3. Contributions Clés

1. Formulation du fossé VD : L'article définit et caractérise la divergence entre un verdict de blocage correct et un diagnostic correct, arguant que les métriques d'évaluation actuelles occultent ce mode de défaillance.
2. MALPR-BENCH : Un cadre d'évaluation systématique et un benchmark qui séparent l'exactitude du verdict de l'identification de la vulnérabilité et de la validation des preuves, en utilisant des rubriques pré-engagées pour la vérité de terrain.
3. PRGUARD : Une architecture d'examinateur de sécurité de PR attribuable qui découple la génération d'hypothèses de la validation des preuves et récupère le contexte au-delà du diff.
4. Validation Empirique : Démonstration que la séparation de l'identification et de la validation améliore l'attribution des découvertes de sécurité, particulièrement pour les défauts de type absence.

4. Résultats

4.1 Performance sur le Jeu de Test de Couverture Commune

Évalué sur 31 PR malveillantes (19 auto-généralisation + 12 cas de découverte) face à CodeRabbit (un examinateur IA commercial largement déployé) :

• Performance de Blocage : Les deux systèmes ont obtenu des taux de blocage similaires (CodeRabbit : 24/31 ; PRGUARD/DeepSeek : 22/31).
• Identification de la Vulnérabilité (I) : PRGUARD/DeepSeek a identifié 1,38× plus de vulnérabilités cibles que CodeRabbit (22 contre 16).
• Défauts de Type Absence : Sur 14 cas où une garde requise était manquante, les deux systèmes ont bloqué 9 PR. Cependant, PRGUARD/DeepSeek a identifié la vulnérabilité cible dans 9/14 des cas, tandis que CodeRabbit ne l'a identifiée que dans 3/14 (une différence de 3×).
• Blocages Attribuables (A) : PRGUARD/DeepSeek a obtenu 19/31 blocages attribuables, contre 16/31 pour CodeRabbit.
• Emplacement des Preuves : CodeRabbit a échoué à identifier les cibles dans 0/7 cas nécessitant des preuves en dehors des fichiers touchés (L2a/L2b), alors que PRGUARD a réussi dans la plupart des cas.

4.2 Évaluation du Pipeline Complet

Sur 63 cas malveillants (excluant le niveau de découverte pour éviter les biais) :

• Pool B (Inversion de l'Application) : Les deux backends (GPT-5.5 et DeepSeek) ont identifié toutes les 37 vulnérabilités cibles (I=37/37). Cependant, la validation des preuves (E) variait (26/37 pour GPT-5.5, 34/37 pour DeepSeek), soulignant que l'identification ne garantit pas un ancrage de preuve valide.
• Contrôles Bénins : PRGUARD a montré de faibles taux de faux positifs (4–5 blocages sur 50 contrôles bénins), comparables à CodeRabbit (0 blocage sur un sous-ensemble de 6 contrôles).

4.3 Découverte en Conditions Réelles

Appliqué à des dépôts de production, PRGUARD a découvert 12 vulnérabilités auparavant non divulguées, appuyées par des preuves de concept, à travers cinq projets largement utilisés.

• Des exécutions indépendantes de PRGUARD et CodeRabbit ont toutes deux bloqué 10/12 PR dans ce niveau de découverte.
• Cependant, PRGUARD a produit 10/12 blocages attribuables, tandis que CodeRabbit n'en a produit que 4/12, démontrant que des totaux de verdicts identiques peuvent masquer une différence de 2,5× dans la qualité du diagnostic.

5. Signification et Revendications

L'article affirme que le fossé Verdict–Diagnostic est une limitation fondamentale de la revue de sécurité automatisée actuelle. Un blocage « réussi » est insuffisant s'il ne parvient pas à identifier et à étayer correctement la vulnérabilité, car cela mène à une remédiation inefficace.

• L'Attribuabilité est la Clé : Les auteurs soutiennent que les revues de sécurité doivent être attribuables — le verdict doit être fondé sur des preuves spécifiques du dépôt qui valident le mécanisme identifié.
• Séparation des Préoccupations : Les résultats suggèrent que séparer les tâches d'identification d'une vulnérabilité candidate et de sa validation par rapport aux preuves améliore la fiabilité du diagnostic, particulièrement pour les défauts complexes nécessitant un contexte multi-fichiers.
• Limitations : L'article reconnaît que PRGUARD n'est pas une solution miracle. Il traite l'injection de prompt et les erreurs de jugement comme des surfaces d'attaque résiduelles. La découverte de vulnérabilités réelles démontre une capacité, mais ne prétend pas estimer le taux de rappel sur des PR arbitraires, car le flux de candidats a été filtré pour une validation manuelle.

En résumé, ce travail déplace l'accent de l'évaluation de « l'a-t-il bloqué ? » vers « l'a-t-il bloqué pour la bonne raison, avec des preuves ? », introduisant une méthodologie et un ensemble d'outils pour mesurer et atténuer les risques de revues de sécurité mal diagnostiquées.