Dans un billet de blog du 24 septembre 2026, GitHub Security Lab a publié en open source Fuzzing Taskflow, un pipeline de fuzzing piloté par LLM : donnez-lui une adresse de dépôt GitHub et il identifie automatiquement les points d'entrée, écrit les harnais de test, lance AFL++, lit les rapports de couverture, améliore les cas de test, puis trie chaque crash en un rapport de vulnérabilité — sans qu'un humain ait à surveiller.
Une commande, et le pipeline tourne tout seul
Le mode d'emploi est presque comiquement simple pour un outil de sécurité. Le code est ouvert sur GitHub (organisation GitHubSecurityLab, projet seclab-taskflows-fuzzing) : ouvrez un Codespace, exécutez ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz, et l'agent s'occupe du reste — installer les dépendances AFL, cloner le dépôt, trouver dans le code les fonctions les plus dignes d'être testées, et générer des cibles de fuzz pour elles.
L'auteur Antonio Morales ajoute dans le billet un avertissement explicite : ce pipeline exécute afl-fuzz, clang et des commandes de build arbitraires choisies par le LLM directement sur la machine hôte, sans aucune isolation par conteneur entre les deux. Un agent victime d'une injection de prompt pourrait théoriquement faire tout ce que le compte utilisateur peut faire ; il ne doit donc tourner que dans des environnements jetables — un Codespace ou une VM à usage unique — et jamais avec des privilèges élevés.
L'agent décide, les outils exécutent
Fuzzing Taskflow est construit sur le framework Taskflow Agent de GitHub Security Lab ; l'ensemble du pipeline est exprimé comme une série de taskflows que l'agent exécute de bout en bout. L'architecture compte trois couches : des scripts shell qui enchaînent les phases, des taskflows YAML qui décrivent les prompts de chaque phase, et des outils MCP qui font le vrai travail — lancer AFL, compiler les harnais, stocker les crashs, lire les rapports de couverture.
La répartition des rôles est claire par design : l'agent LLM détient le pouvoir de décision — quoi tester, quel type de harnais écrire, quelle lacune de couverture poursuivre ensuite — tandis que les outils MCP n'exposent que des primitives d'exécution. L'agent n'appelle jamais AFL ou clang directement ; il assemble le pipeline à partir de ces briques. Tout l'état des phases vit dans une base SQLite ; les phases ne se transmettent jamais de données en mémoire directement.
Le modèle par défaut est Claude Sonnet 5, choisi parce qu'il a passé l'intégralité des tests internes sans déclencher les garde-fous de sécurité ; pour changer de modèle, il suffit de modifier src/seclab_taskflows_fuzzing/configs/model_config.yaml.
Le cœur, c'est la boucle de rétroaction de couverture
Les deux étapes les plus pénibles du fuzzing manuel sont la lecture des rapports de couverture pour trouver les branches non couvertes et l'écriture de nouveaux harnais pour elles. Fuzzing Taskflow confie les deux à l'agent : chaque round accorde à chaque harnais un budget de temps d'exécution AFL, rejoue ensuite la file pour produire la vraie couverture de lignes et de branches, lit les branches non couvertes, puis choisit une action — ajouter une graine visant directement cette branche, étendre le harnais pour appeler une autre API, ajouter automatiquement au dictionnaire AFL les constantes magiques des conditions de garde, ou juger qu'il s'agit d'un chemin d'erreur obscur et passer.
Le budget de temps double à chaque round : 30 secondes, 60 secondes, 120 secondes, jusqu'à environ 32 minutes. Quand s'arrêter ? Grâce à un « détecteur de plateau » : deux rounds consécutifs avec des gains absolus de couverture de lignes inférieurs à 1 % signifient des rendements décroissants — on passe à la cible suivante plutôt que de brûler du calcul pour les derniers dixièmes de pourcent.
Pour les entrées structurées (JSON, XML, expressions régulières, PNG et consorts), le pipeline embarque quatre mécanismes complémentaires : des dictionnaires de formats pré-ensemencés plus des mutateurs sur mesure, des dictionnaires au niveau source générés automatiquement en scannant les constantes de chaînes dans le code source de la cible, des dictionnaires à croissance dynamique indexés sur la couverture, et des opérateurs de splicing de corpus.
Le tri des crashs, la partie la plus fastidieuse, est aussi automatisé
Trouver un crash n'est que la moitié du travail ; le tri coûte généralement plus de temps. Après le fuzzing, le pipeline enchaîne automatiquement trois étapes : minimiser chaque crash avec afl-tmin, le rejouer sous ASan pour capturer les piles, et dédupliquer par « hash du sommet de pile » ; rejouer ensuite tous les crashs historiquement connus contre le nouveau binaire pour voir si des correctifs upstream les ont déjà résolus ; enfin, l'agent lit le source du harnais et la fonction en crash, remonte la chaîne d'appels et rédige un rapport Markdown par crash.
Chaque rapport porte un verdict : vraie vulnerability, library_hardening, bug dans le harnais lui-même, OOM, timeout, échec d'assertion ou doublon. Distinguer « un vrai bug » de « le harnais a été mal écrit » — c'est exactement le jugement qui exigeait autrefois un humain assis à tracer le code ligne par ligne. Chaque rapport contient aussi une analyse de cause racine (avec fichiers et numéros de ligne), un argument de joignabilité, une évaluation d'exploitabilité, une suggestion de correctif en diff unifié marquée « nécessite une revue humaine » et une esquisse de test de régression.
Une fois lancé, un tableau de bord en direct sur le port 8765 affiche le battement de cœur de chaque harnais, les tendances de couverture, les cartes de chaleur des crashs et les chronologies d'itération.
Les mainteneurs open source peuvent l'essayer
Les bénéficiaires les plus directs sont les mainteneurs de projets C/C++ open source qui « savent qu'ils devraient fuzzer mais n'ont personne pour ça » : après l'adoption d'OSS-Fuzz, écrire les harnais, surveiller la couverture et trier les crashs prenait encore des humains — l'agent reprend désormais cette partie. Bien sûr, Morales lui-même concède que le verdict de l'agent n'est qu'un « point de départ bien préparé », pas une conclusion finale — c'est pour cela que les suggestions de correctif des rapports sont marquées « à réviser ».
Fait notable : GitHub n'est pas la seule maison à pousser l'IA dans la sécurité du code. Nous avons précédemment couvert le Security Reviewer de Cursor, qui prend la voie du « scan de chaque PR » ; le pipeline de GitHub prend la voie du « fuzzing en profondeur ». L'un garde le code incrémental, l'autre le code hérité — ils se complètent parfaitement.
