💻 computer science

Security in a Workflow: Exploring Role-Based Agentic Architectures for Vulnerability Handling

Cet article propose et évalue un flux de travail agentique basé sur des rôles comprenant des agents Planificateur, Analyste, Correcteur et Vérificateur afin de combler l'écart entre les tâches de sécurité isolées des LLM et les pratiques industrielles réelles, démontrant une précision de détection de vulnérabilité de 44 % et une précision de correction de 19 % sur 25 vulnérabilités C/C++ réelles.

Auteurs originaux : Srijita Basu, Miroslaw Staron

Publié 2026-06-15

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Srijita Basu, Miroslaw Staron

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 essayez de réparer une maison très ancienne et complexe (un programme informatique écrit en C ou C++) qui présente des fissures cachées et des points faibles (des vulnérabilités de sécurité). Par le passé, vous auriez pu engager un détective unique et super intelligent (une IA standard) pour inspecter la maison, trouver les fissures et essayer de toutes les colmater en une seule fois. Parfois, ce détective réussit, mais souvent, il est dépassé, manque des indices subtils ou répare le mauvais mur.

Ce document propose une approche différente : engager une équipe d'agents spécialisés plutôt qu'un détective solitaire. Ils travaillent ensemble selon une chaîne de montage stricte, où chacun a un travail spécifique.

Voici comment l'équipe fonctionne, en utilisant les conclusions du document :

1. Les rôles de l'équipe (le « flux de travail agentique »)

Les chercheurs ont mis en place une équipe numérique avec quatre rôles distincts, semblables à une équipe de construction :

Le Planificateur (Le Chef de Chantier) : Avant que quiconque ne commence à creuser, cet agent scanne les plans (le code) pour repérer les points de friction évidents. Il ne répare rien ; il indique simplement à l'équipe les zones qui semblent suspectes, comme « Vérifiez la porte arrière » ou « Regardez les fondations ».
- Résultat clé : Le document a constaté que le fait d'avoir ce « Chef de Chantier » était crucial. Lorsqu'ils ont supprimé ce rôle, la capacité de l'équipe à trouver des problèmes a chuté de près de moitié.
L'Analyseur (L'Inspecteur) : C'est le détective principal. Il prend les indices du Planificateur et le code brut pour comprendre exactement ce qui est cassé, pourquoi c'est cassé et comment un cambrioleur pourrait s'introduire.
- Résultat clé : Les chercheurs ont tenté de donner à cet agent un détecteur de métaux sophistiqué (un outil appelé CodeQL) pour l'aider à trouver les fissures. Étonnamment, le détecteur de métaux n'a pas toujours aidé. Parfois, il générait trop de fausses alertes, ce qui a confondu l'Inspecteur. Les meilleurs résultats sont venus du fait que le modèle d'IA lui-même effectuait la réflexion profonde, plutôt que de s'appuyer lourdement sur l'outil supplémentaire.
Le Réparateur (L'Ouvrier) : Une fois que l'Inspecteur dit : « Le cadre de la porte pourrit », le Réparateur essaie de construire une nouvelle porte. Il écrit le code pour colmater la brèche.
- Résultat clé : C'était le travail le plus difficile. Bien que l'équipe ait été correcte pour trouver le problème (environ 44 % de précision), le réparer correctement était beaucoup plus difficile (seulement environ 19 % de précision). Souvent, le Réparateur colmata le trou mais cassait accidentellement quelque chose à proximité ou ajoutait des éléments inutiles.
Le Vérificateur (L'Inspecteur de Sécurité) : Une fois la réparation terminée, cet agent vérifie le travail. Il demande : « Avez-vous réellement réparé la pourriture ? Avez-vous rendu la maison plus sûre, ou avez-vous simplement peint par-dessus la fissure ? »
- Résultat clé : Ce rôle a été assez efficace pour repérer les erreurs, capturant environ 69 % des erreurs dans les réparations.

2. L'expérience

Les chercheurs ont testé cette équipe sur 25 failles de sécurité réelles trouvées dans des logiciels C/C++ populaires (comme ceux utilisés dans les systèmes critiques pour la sécurité). Ils ont utilisé trois « cerveaux » différents (modèles d'IA) pour alimenter les membres de l'équipe.

Ils ont comparé deux versions de l'équipe :

Équipe A : Juste les quatre rôles communiquant entre eux.
Équipe B : Les mêmes quatre rôles, mais l'Inspecteur a reçu le détecteur de métaux CodeQL pour l'aider à trouver les fissures.

3. Ce qu'ils ont découvert

Le « Manager » est le plus important : La partie la plus importante du processus était le Planificateur. Sans un manager pour guider l'équipe sur l'endroit où regarder, l'IA se perdait. Avec le manager, l'équipe a obtenu des performances comparables à une IA commerciale de haut niveau (GPT-5.5) pour trouver les bugs.
Les outils ne sont pas magiques : Donner un outil sophistiqué (CodeQL) à l'Inspecteur n'a pas automatiquement amélioré ses performances. En fait, cela a parfois aggravé les choses car l'IA avait du mal à interpréter correctement les données de l'outil. Le document suggère que pour les langages informatiques de bas niveau (comme le C), l'IA doit être assez intelligente pour prioriser elle-même les indices.
Trouver vs Réparer : Il est beaucoup plus facile pour une IA de trouver une faille de sécurité que de la réparer. L'équipe a trouvé les bugs environ 44 % du temps, mais ne les a réparés correctement que 19 % du temps.
La touche humaine est toujours nécessaire : Comme le « Réparateur » (le Fixer) faisait souvent des erreurs ou ajoutait des changements inutiles, le document conclut qu'en matière de sécurité réelle, on ne peut pas laisser l'IA diriger seule. Vous avez besoin d'un humain pour surveiller l'IA, vérifier les réparations et s'assurer que la maison est réellement sûre.

L'essentiel

Ce document ne prétend pas que l'IA peut désormais sécuriser parfaitement les logiciels de manière autonome. Au lieu de cela, il montre que organiser l'IA en une équipe structurée avec des rôles clairs est une meilleure méthode pour gérer la sécurité que de laisser une seule IA tout faire. Cependant, même avec une excellente équipe, la partie « réparation » reste délicate, et les experts humains sont toujours essentiels pour vérifier le travail.

Résumé Technique : La sécurité dans un flux de travail – Exploration des architectures d'agents basées sur les rôles pour la gestion des vulnérabilités

Problématique

L'ingénierie logicielle sécurisée en pratique industrielle implique un flux de travail structuré et multi-étapes comprenant l'analyse des vulnérabilités, la remédiation et la vérification des correctifs. Cependant, les approches actuelles basées sur les modèles de langage de grande taille (LLM) pour la sécurité logicielle sont souvent fragmentées, se concentrant sur des tâches isolées telles que la détection ou la génération de correctifs, plutôt que de refléter les flux de travail agentiques de bout en bout utilisés dans les processus de sécurité réels. Cela crée un fossé entre les méthodes existantes de LLM et l'ingénierie logicielle sécurisée pratique, particulièrement pour les langages système de bas niveau comme le C et le C++. Dans ces langages, les vulnérabilités dépendent de la sémantique complexe de la mémoire, de la manipulation de pointeurs et de la gestion des tampons (buffers), ce qui rend le diagnostic et la remédiation difficiles pour les LLM. De plus, l'exploration des flux de travail agentiques augmentés par des outils et de l'intégration de compétences via le protocole MCP (Model Context Protocol) est limitée, spécifiquement pour ces contextes de bas niveau.

Méthodologie

Les auteurs proposent et évaluent un flux de travail agentique basé sur les rôles, conçu pour décomposer la gestion des vulnérabilités en étapes explicites : planification de l'investigation, analyse de la vulnérabilité, génération de correctifs et vérification du correctif.

Conception du flux de travail

L'étude implémente deux variantes de flux de travail utilisant le framework CrewAI, instanciées avec trois LLM open-source : nemotron-cascade-2:30b, qwen3-coder-next, et gpt-oss:120b. Les flux de travail consistent en quatre rôles distincts :

Planificateur (Planner) : Un module statique basé sur des règles (non LLM) qui scanne le code C d'entrée pour des modèles de vulnérabilités prédéfinis (ex: dépassements de tampon, déréférencement de pointeur nul) en utilisant des expressions régulières. Il produit des régions d'investigation et des thèmes prioritaires pour guider l'Analyseur.
Analyseur (Analyzer) : Un agent LLM responsable du diagnostic technique. Il détermine la vulnérabilité principale, assigne l'identifiant CWE (Common Weakness Enumeration), identifie les lignes vulnérables, explique la cause racine et trace le flux source-vers-puits (source-to-sink).
- Flux de travail 1 : L'Analyseur repose uniquement sur les directives du Planificateur.
- Flux de travail 2 : L'Analyseur est augmenté par une intégration MCP CodeQL, fournissant des capacités d'analyse statique pendant le diagnostic.
Correcteur (Fixer) : Un agent LLM qui génère un correctif sécurisé minimal basé sur le diagnostic de l'Analyseur. Il est contraint de produire uniquement le correctif et une explication concise, évitant ainsi le rediagnostic.
Vérificateur (Verifier) : Un agent LLM indépendant qui évalue si le correctif généré résout la vulnérabilité identifiée, élimine la cause racine et évite l'introduction de régressions.

Configuration expérimentale

Jeu de données : Un ensemble curaté de 25 CVE (Common Vulnerabilities and Exposures) réelles en C/C++ couvrant cinq catégories CWE : CWE-787 (Écriture hors limites), CWE-476 (Déréférencement de pointeur nul), CWE-190 (Dépassement d'entier), CWE-125 (Lecture hors limites) et CWE-191 (Sous-dépassement d'entier).
Vérité de terrain (Ground Truth) : Dérivée des descriptions de la NVD (National Vulnerability Database) et du code patché fourni par les développeurs.
Évaluation : Évaluation manuelle basée sur une grille de notation par deux auteurs (kappa de Cohen $\kappa = 0,83$ ) comparant les sorties des agents à la vérité de terrain. Les métriques incluaient la précision de détection (assignation CWE, identification de ligne, cause racine) et la précision du correctif (similarité sémantique avec les correctifs de confiance).
Portée : L'étude est une évaluation exploratoire orientée méthodologie plutôt qu'un benchmark à grande échelle, se concentrant sur 150 exécutions de flux de travail (25 CVE $\times$ 3 modèles $\times$ 2 variantes).

Principales contributions

Architecture agentique basée sur les rôles : Proposition et évaluation d'un flux de travail de bout en bout séparant la planification, l'analyse, la correction et la vérification, démontrant comment la séparation explicite des rôles peut structurer les activités de sécurité.
Conception d'un planificateur statique : Implémentation d'un planificateur basé sur des règles pour guider l'investigation des vulnérabilités dans des projets C pertinents pour l'industrie, montrant son impact critique sur la qualité de la détection.
Ensemble de référence curaté : Mise à disposition de 25 instances de vulnérabilités C/C++ réelles avec métadonnées de vérité de terrain, correctifs de développeurs et sorties de LLM, ainsi que le code du framework CrewAI pour la reproductibilité.
Analyse de l'intégration des outils : Étude de l'efficacité de l'intégration de l'analyse statique basée sur MCP (CodeQL) dans l'étape d'analyse d'un flux de travail multi-agents.

Résultats

L'étude rapporte les métriques de performance suivantes (en utilisant nemotron-cascade-2:30b comme modèle principal de comparaison) :

Précision de détection :
- Flux de travail 1 (Sans CodeQL) : A atteint 44 % de précision de détection, comparable aux baselines de GPT-5.5.
- Flux de travail 2 (Avec CodeQL) : La précision est tombée à 31 %, suggérant que l'intégration d'outils ne garantit pas l'amélioration si l'agent ne peut pas interpréter ou prioriser correctement les indices de l'outil.
- Ablation : Le retrait du Planificateur a réduit la précision de détection à 25 % (sans CodeQL) et 19 % (avec CodeQL), soulignant le rôle critique du Planificateur.
Précision du correctif :
- La précision globale du correctif était faible, à 19 % pour le Flux de travail 1 et 13 % pour le Flux de travail 2.
- La réparation s'est avérée nettement plus difficile que la détection. Bien que certains correctifs aient été "comparables" ou même "meilleurs" que la vérité de terrain (particulièrement pour CWE-476 et CWE-787), beaucoup contenaient une logique inutile ou introduisaient de nouveaux bugs.
Précision du Vérificateur :
- Le Vérificateur a atteint 69 % de précision avec nemotron-cascade-2:30b, indiquant une capacité plus forte dans l'évaluation post-remédiation que dans la génération.
Variabilité des CWE : Les CWE-787 et CWE-476 étaient les plus faciles à détecter, tandis que le CWE-191 (Sous-dépassement d'entier) restait le plus difficile à travers tous les modèles et configurations.

Signification et affirmations

Le papier positionne ce travail comme une étude exploratoire initiale plutôt qu'un benchmark définitif. Sa signification principale réside dans :

Amélioration des processus : Démontrer que la décomposition des tâches de sécurité en étapes structurées et basées sur les rôles (Planification, Analyse, Correction, Vérification) peut rendre les activités de sécurité plus répétables et transparentes.
Nécessité de l'humain dans la boucle (Human-in-the-Loop) : Réaffirmer que malgré les progrès des LLM, la qualité inégale des correctifs générés et l'efficacité mitigée de l'intégration des outils nécessitent une supervision humaine continue dans les contextes critiques de la sécurité.
Le Flux de travail avant le Modèle : Déplacer l'attention de la sélection du "meilleur" modèle vers l'affinement de l'architecture du flux de travail sous-jacent et des techniques d'intégration. Les auteurs notent que si le criblage des modèles est essentiel, la conception du flux de travail est le levier principal d'amélioration.
Nuance de l'intégration des outils : Souligner que l'intégration d'outils comme CodeQL nécessite une conception d'agent minutieuse pour garantir que les indices sont priorisés correctement ; ajouter simplement des outils n'améliore pas automatiquement les performances.

Les auteurs concluent que les architectures agentiques basées sur les rôles constituent une direction prometteuse pour l'amélioration des processus de développement logiciel sécurisé, motivant des travaux futurs sur des ensembles de données plus larges, l'analyse au niveau du dépôt et des alternatives de flux de travail raffinées (ex: analyseurs multiples, boucles de raffinement).