Construction d'un Dataset Cybersécurité par Agents IA & Fine-Tuning d'un LLM SAST

Ce projet vise à concevoir un modèle souverain d’audit de sécurité de code source (Static Application Security Testing). En s’appuyant sur des pipelines d’agents pour collecter, nettoyer et distiller des données de vulnérabilités, un jeu de données de haute qualité de plus de 20 000 échantillons a été constitué. Un modèle open-source (Qwen 3.6 27B) a ensuite été fine-tuné en QLoRA (FP8) sur ce dataset, offrant une solution souveraine, bas coût et protégeant le code sensible.

Contexte

Ce travail a été réalisé dans le cadre de mon stage de fin d’études de 6 mois chez Orange, au sein de l’équipe sécurité DEFY.

Face aux cyberattaques de plus en plus fréquentes et sophistiquées, notamment propulsées par l’IA, le passage à l’IA pour la défense est devenu primordial. Les solutions traditionnelles présentent des limites majeures :

• Outils SAST classiques : Ils affichent un taux de faux positifs extrêmement élevé, surchargeant les équipes de sécurité d’alertes non pertinentes.
• Modèles propriétaires/API tierces : Les solutions commerciales sont chères, leurs tarifs augmentent constamment, et l’envoi de code source sur des serveurs tiers non souverains empêche d’auditer des applications internes sensibles.

L’objectif de la mission était donc de concevoir une alternative souveraine, locale et performante : construire un dataset de cybersécurité pour entraîner un modèle open-source, déployable sur des serveurs on-premises d’Orange, garantissant la confidentialité des données et un coût d’exploitation maîtrisé.

Données

La constitution d’un dataset d’entraînement de qualité représentait le premier grand défi, car les bases de données publiques manquent cruellement de contexte de code exploitable.

• Bases de données de vulnérabilités : Exploitation de sources recensant les CVEs comme le NVD, Github Advisory Database, Snyk et OSV.
• Bases incomplètes : Les bases de CVE publiques ne fournissent souvent qu’une explication succincte en texte et un lien vers le commit de correction. Elles ne contiennent pas directement les portions de code incriminées, ce qui rend l’entraînement direct impossible.
• Rapports internes : Accès à des rapports d’audit d’applications internes d’Orange et à des rapports de programmes de Bug Bounty.

Méthodologie

Le pipeline de développement s’est structuré autour de ces étapes clés, allant de la collecte automatisée à l’évaluation en conditions réelles.

1. Scraping et extraction par Agents IA

Pour récupérer le code vulnérable et son contexte associé aux CVEs publiques, un pipeline agentique basé sur le framework LangGraph et connecté à des outils spécialisés a été développé :

• Serena MCP : Permet à l’agent d’explorer dynamiquement les dépôts Git et d’en extraire le contexte métier.
• Tree-Sitter : Génère les arbres de syntaxe abstraite (AST) pour construire un graphe des méthodes reliant les appelants et les appelés.
• Routage de LLMs : L’agent s’appuyait sur Claude Haiku 4.5 pour les tâches standards d’exploration, avec une escalade automatique vers Sonnet 4.6 en cas de blocage ou d’échec, le tout structuré avec des formats de sortie JSON stricts.
• Résultat : Récupération de près de 25 000 échantillons de vulnérabilités contenant le code source, le contexte métier, le patch appliqué et la description associée.

2. Filtrage du bruit

Les datasets de cybersécurité bruts contiennent énormément de bruit (code de test, commits vides, erreurs d’association). Pour y remédier :

• Filtre sémantique : Un premier tri sémantique a éliminé les échantillons sans code ou manifestement hors-sujet.
• Pipeline d’évaluation agentique : Un second pipeline d’évaluation (propulsé par Sonnet 4.6) a analysé en profondeur chaque échantillon restant pour valider le lien réel entre le code extrait et la faille décrite, écartant les faux positifs.

3. Distillation de connaissances et Chain-of-Thought (CoT)

Afin d’apprendre au modèle à raisonner comme un analyste de sécurité, l’utilisation des descriptions de vulnérabilités brutes, trop hétérogènes, a été écartée.

• Génération de CoT : Un LLM de “professeur” (Sonnet 4.6) a été utilisé pour rédiger des explications détaillées décrivant le flux complet des données utilisateur sensibles (de la sources vers les sinks) et la faille d’exploitation.
• Explications des patchs & Hard Negatives : Des analyses détaillées des corrections (ex: implémentation d’un sanitizer) ont également été rédigées, démontrant pourquoi le code patché est sécurisé. Le dataset a ainsi été divisé à parts égales (50% vulnérable avec explication de la faille / 50% sécurisé avec explication de la correction).
• Résultat : Un jeu de données final de très haute qualité comptant plus de 20 000 échantillons équilibrés couvrant tous les langages web et la majorité des CWEs.

4. Fine-Tuning en QLoRA

Pour adapter le modèle à la tâche tout en respectant les contraintes de budget matériel :

• Sélection du Modèle : Après analyse comparative des benchmarks de cybersécurité dans la catégorie <35B paramètres, le choix s’est porté sur Qwen 3.6 27B. Sa version dense s’est révélée plus performante pour le raisonnement logique complexe requis en sécurité que la version Mixture of Experts (Qwen 3.6 35B A3B).
• Quantization FP8 native : Pour diviser par deux l’empreinte mémoire avec des pertes de performance négligeables, le format FP8 a été privilégié. Plutôt que de quantizer le modèle de manière personnalisée en 4 bits avec Unsloth, les poids FP8 officiels de l’éditeur sur Hugging Face ont été utilisés.
• Matériel & Entraînement : Cette configuration en FP8 natif nécessitant un GPU supportant l’architecture matérielle FP8, l’entraînement a été réalisé via la bibliothèque Transformers sur un GPU NVIDIA H100 (80 Go) de GCP.

5. Déploiement et architecture LoRA

Le modèle a été déployé en production à l’aide de vLLM sur un cluster de deux GPU NVIDIA L4 (24 Go VRAM chacun). vLLM permet d’exécuter la base du modèle tout en chargeant dynamiquement la surcouche LoRA fine-tunée. Cette architecture flexible permet d’inférer avec ou sans la surcouche de sécurité pour l’évaluation comparative du modèle finetuné par rapport au modèle baseline.

6. Protocole d’Évaluation

La validation de la pertinence de ce LLM SAST repose sur trois étapes :

1. Évaluation académique : Test sur 10% du dataset qui a été exclu de la phase d’entraînement (validation classique).
2. Cas d’usage réel : Audit d’une application préalablement testée par les pentesters de l’équipe afin de vérifier si le modèle parvient à identifier les mêmes vulnérabilités sans générer de faux positifs.

Résultats

Le projet a abouti à la création d’un modèle souverain performant, spécialisé dans l’analyse statique de code de sécurité (SAST), déployable localement et garantissant la confidentialité absolue du code source.