GitHub Security Lab vient de publier un exemple concret de recherche de sécurité assistée par des agents, au-delà d’une simple revue généraliste du code. L’équipe affirme avoir trouvé et signalé 24 vulnérabilités dans des applications Android en utilisant GitHub Security Lab Taskflow Agent, son cadre open source, ainsi qu’un ensemble de flux d’audit réutilisables.
Le système n’est pas présenté comme un chercheur en sécurité entièrement autonome. GitHub décompose l’audit en étapes explicites, utilise des consignes structurées pour guider les modèles, répète certaines analyses afin de limiter les oublis, puis confie la validation finale à des chercheurs en sécurité. Taskflow Agent est un cadre multi-agent compatible avec MCP et piloté par une grammaire déclarative en YAML ; le dépôt SecLab Taskflows fournit, de son côté, des exemples de flux d’audit et des outils complémentaires.
La différence est importante. La nouveauté ne tient pas seulement à la capacité d’un modèle de langage à lire du code. GitHub transforme une partie de la méthode d’un spécialiste en processus reproductible, versionnable et partageable.
Le flux d’audit rend la méthode explicite
Pour l’audit Android, le travail est divisé en tâches plus étroites. Une étape identifie les points d’entrée propres aux applications mobiles ; une autre demande au modèle d’examiner autour de ces points des classes de vulnérabilités spécifiques à Android. GitHub décrit également l’usage de plusieurs exécutions et de consignes à la fois strictes et plus ouvertes afin de réduire les oublis tout en laissant au modèle la possibilité de rechercher des failles logiques moins prévisibles.
Le flux devient ainsi un artefact que l’équipe peut examiner. Un chercheur peut vérifier l’ordre des tâches, les consignes et les outils au lieu de considérer le modèle comme une boîte noire. Le dépôt associé permet d’exécuter ces flux dans un Codespace ou localement, même si GitHub précise que les audits peuvent prendre plusieurs heures et provoquer un grand nombre d’appels aux modèles.
Pour Aipolix, la conséquence architecturale est claire : la qualité d’un système de sécurité agentique dépend de plus en plus de l’orchestration, et pas uniquement du niveau du modèle. La décomposition de l’enquête, la transmission des éléments de preuve entre les étapes et la validation finale déterminent une grande partie de la valeur opérationnelle.
GitHub annonce 24 vulnérabilités Android
Dans sa publication du 28 septembre, GitHub Security Lab indique que les flux avaient permis de trouver et de signaler 24 vulnérabilités Android. L’article présente notamment des cas liés à des activités Android exportées, au comportement de WebView et aux interactions entre applications. GitHub souligne que la méthode peut mettre au jour des failles logiques et ne se limite donc pas à une détection par motifs simples.
L’intérêt opérationnel vient du caractère réutilisable de la méthode. Une équipe peut formaliser une stratégie d’audit, l’améliorer puis l’appliquer à un autre dépôt. Ce fonctionnement est différent d’une requête unique adressée à un assistant de programmation pour lui demander de « trouver des vulnérabilités ».
Les dépôts publics rendent aussi l’approche vérifiable. Taskflow Agent utilise des flux définis en YAML et peut se connecter à des outils via MCP. SecLab Taskflows fournit des exemples pour l’audit et d’autres travaux de recherche en sécurité. Cela ne démontre pas que le même rendement sera obtenu sur n’importe quelle base de code, mais les équipes disposent d’une mise en œuvre qu’elles peuvent réellement étudier.
La validation humaine reste la frontière de contrôle
GitHub décrit sans ambiguïté les limites de la méthode. Les modèles peuvent signaler des problèmes de faible gravité ou difficiles à exploiter en pratique. Ils peuvent aussi mal évaluer la sévérité lorsqu’ils ne voient pas un mécanisme de réduction du risque situé ailleurs dans l’application. Dans certains cas, il faut construire une preuve de concept ou exécuter le programme avec un débogueur pour déterminer si la vulnérabilité est réelle.
Le chiffre de 24 ne doit donc pas être interprété comme la preuve qu’un agent peut remplacer un chercheur expérimenté. Les résultats sont rapportés par GitHub Security Lab et n’ont pas été reproduits indépendamment au cours de cette exécution Research.
Il existe aussi des contraintes pratiques. GitHub précise que les flux peuvent provoquer de nombreux appels d’outils et de modèles, durer plusieurs heures sur de gros dépôts et nécessiter par défaut un accès à GitHub Copilot. Les coûts et la capacité d’exécution deviennent donc importants pour une utilisation continue à grande échelle.
La conclusion la plus solide est plus limitée : des flux structurés peuvent rendre certaines parties de la recherche de vulnérabilités plus reproductibles et plus faciles à étendre, mais la décision de sécurité finale doit rester validée.
L’actif réutilisable est le processus d’enquête
La leçon principale est que l’élément durable peut être le flux de travail plutôt que la sortie ponctuelle du modèle. Un flux peut enregistrer la manière dont un chercheur délimite l’audit, les surfaces d’attaque prioritaires, les outils utilisés et les étapes auxquelles les preuves doivent être contrôlées de nouveau.
Cela crée une nouvelle surface d’ingénierie pour la sécurité applicative. Les équipes peuvent versionner leurs méthodes d’audit, examiner les modifications des consignes et des outils, comparer plusieurs modèles et intégrer des contrôles propres à leur organisation.
Cette programmabilité soulève aussi des questions de gouvernance. Un flux peut lire du code source, invoquer des outils externes et générer un volume important de requêtes vers les modèles. Il faut donc encadrer les autorisations, les identifiants, le traitement des données et la provenance de chaque constat. Le dépôt de GitHub avertit d’ailleurs que l’image de conteneur fournie facilite le déploiement mais ne constitue pas une frontière de sécurité.
La conclusion d’Aipolix est que ce travail est significatif parce qu’il rend programmable une partie d’une méthode experte de recherche en sécurité. Le modèle compte, mais l’innovation la plus transférable réside dans la combinaison d’une décomposition explicite des tâches, d’outils, d’une logique d’audit réutilisable et d’une validation humaine.