Antonio Morales, chercheur au GitHub Security Lab, a publié le 24 septembre un pipeline de fuzzing piloté par un grand modèle de langage, destiné aux projets C/C++. Le code se trouve dans le dépôt GitHub seclab-taskflows-fuzzing, et le modèle par défaut est Claude Sonnet 5.
Le système repose sur Taskflow Agent, le framework maison de GitHub, décrit officiellement comme "un framework pour écrire de l'automatisation de sécurité pilotée par LLM". L'utilisateur ouvre un Codespace dans le dépôt, exécute une ligne de commande suivie du nom du projet cible, par exemple tukaani-project/xz, et laisse l'agent gérer le reste.
De la recherche du point d'entrée au rapport final
D'après la description, le pipeline exécute ces étapes dans l'ordre : identifier les points d'entrée dans le code, rédiger automatiquement un harness de test, appeler AFL++ pour lancer le fuzzing, lire le rapport de couverture, réécrire le harness en fonction de la couverture obtenue, classer chaque plantage (crash) un par un, puis générer un rapport de vulnérabilité accompagné d'une suggestion de correctif au format diff unifié.
Le retour de couverture repose sur un budget de temps qui double à chaque cycle : il démarre à 30 secondes, puis passe à 60, 120, 240, 480 et 960 secondes, soit environ 32 minutes cumulées par cible. Après chaque cycle, l'agent examine la couverture avant de décider quoi ajuster ensuite.
Pour que la mutation aléatoire comprenne mieux le format des entrées, le pipeline superpose quatre couches "conscientes de la structure" : des dictionnaires et mutateurs propres à chaque format de fichier, des dictionnaires extraits du code source lui-même, des dictionnaires AFL générés dynamiquement pendant l'exécution, et la technique d'assemblage de corpus (splicing).
La classification des plantages est assez fine : vulnérabilité réelle (vulnerability), recommandation de durcissement de bibliothèque (library_hardening), bug du harness lui-même (harness_bug), épuisement mémoire, dépassement de délai, échec d'assertion et doublon. Les plantages passent d'abord par une minimisation avec afl-tmin, puis sont dédupliqués selon la pile d'appels. Pendant l'exécution, un tableau de bord HTML sur le port 8765 permet de suivre la progression en temps réel.
Morales pose un principe de répartition des rôles très clair pour cette conception :
"the LLM agent owns the decisions, and the MCP tools own the execution"
(Les décisions reviennent à l'agent LLM, l'exécution aux outils MCP.)
Face à la démarche d'OSS-Fuzz
Intégrer des LLM dans le fuzzing, Google s'y est mis plus tôt. OSS-Fuzz expérimente depuis 2023 l'usage de LLM pour générer automatiquement des fuzz targets, et fin 2024 Google avait annoncé publiquement que cette approche avait permis de trouver plusieurs problèmes, dont une vulnérabilité dans OpenSSL. Cette solution résout surtout l'étape "écrire le harness" ; le projet lui-même doit d'abord être intégré à l'infrastructure d'OSS-Fuzz.
Cette fois, l'approche de GitHub ressemble davantage à une boîte à outils transportable : elle n'exige aucune intégration à une plateforme, il suffit d'ouvrir un environnement de développement dans le cloud pour l'exécuter, et le triage comme la rédaction du rapport sont déjà inclus. Dès le début, l'article rappelle que le fuzzing continu n'est pas une solution miracle : des projets présents depuis des années sur OSS-Fuzz peuvent encore cacher des bugs graves, ce qui explique aussi le choix de xz comme démonstration. xz a connu en 2024 un incident de porte dérobée qui a secoué toute la communauté open source, mais il s'agissait d'une attaque d'empoisonnement délibérée, une catégorie différente des erreurs mémoire que le fuzzing peut détecter.
Ce que l'article ne dit pas
Plusieurs chiffres qui intéressent le plus les observateurs extérieurs n'ont pas été communiqués : combien de plantages ont été trouvés sur xz et cJSON, combien d'entre eux ont été jugés comme de véritables vulnérabilités, si des CVE ont été attribués ; la consommation de tokens et le coût pour aller au bout d'un projet ; le taux de faux positifs. Le ton de l'auteur lui-même reste assez mesuré : il écrit que les conclusions du triage doivent être vues comme "un point de départ bien préparé à remettre à un humain", et non comme un résultat final, et que les suggestions de correctif sont elles aussi toutes marquées comme nécessitant une relecture humaine.
Sur le plan de la sécurité, il y a encore une réserve. Le pipeline ne fait pas d'isolation par conteneur pendant son exécution ; il est officiellement recommandé de ne le faire tourner que dans un Codespace ou une machine virtuelle temporaire, c'est-à-dire des environnements jetables, et de ne pas lui accorder de privilèges élevés. Pour les équipes qui envisageraient un déploiement direct sur le réseau interne de l'entreprise, cette barrière se présente avant même le choix du modèle.
Pour les mainteneurs de bibliothèques open source en Chine, le principal obstacle se situe au niveau du modèle : la configuration par défaut appelle un modèle d'Anthropic, et la connexion directe depuis la Chine n'est pas pratique. Le dépôt étant ouvert, il serait en théorie possible de basculer vers un autre modèle compatible, mais aucun test public n'a pour l'instant confirmé si les performances se maintiennent.
Sources : blog officiel de GitHub, description du dépôt open source seclab-taskflows-fuzzing, CocoLoop, documents publics sur OSS-Fuzz de Google ; les étapes du pipeline, le budget de temps et la classification des plantages suivent la description du blog de GitHub.