Kevin Stubbings, chercheur au GitHub Security Lab, a publié le 28 septembre un billet expliquant comment son équipe a utilisé l'agent d'IA de sécurité open source maison de GitHub pour auditer des applications Android, trouvant et signalant au total 24 vulnérabilités. L'outil utilisé s'appelle seclab-taskflow-agent, dont le cœur est un ensemble de "taskflows" écrits en YAML qui guident, étape par étape, un grand modèle de langage pour lire le code, classer les points d'entrée, repérer les problèmes et rédiger des preuves de concept.
Ces taskflows servaient jusqu'ici à des audits de code généraux ; ils ont cette fois été adaptés spécifiquement au mobile, avec l'ajout de deux nouveaux fichiers, gather_mobile_entry_point_info.yaml et classify_application_local.yaml, chargés respectivement de recenser les points d'entrée d'une application et de classer les vulnérabilités.
Comment ça fonctionne
Selon le processus décrit dans l'article, l'utilisateur exécute un script d'audit dans GitHub Codespaces, attend quelques minutes que l'environnement s'initialise, puis laisse l'agent travailler seul. Pour un dépôt de taille moyenne, l'opération prend environ une à deux heures. Les résultats sont écrits dans une base de données SQLite : il suffit d'ouvrir la table audit_results et de filtrer les entrées dont la colonne has_vulnerability est cochée pour voir les points que l'agent juge problématiques.
Les types de vulnérabilités couverts par le taskflow portent sur des problèmes classiques d'Android : confused deputy et broadcasts non sécurisés liés aux Intents, scripts inter-applications dans les WebViews, ponts JavaScript exposés aux pages web, path traversal, erreurs de logique dans la résolution des deep links, ainsi que fuites de cookies et de jetons de connexion. L'article indique que la liste de classification couvre au total 12 catégories CWE.
Deux cas détaillés
OsmAnd, une application de cartographie et de navigation open source comptant plus de 10 millions de téléchargements. L'agent a trouvé 3 problèmes dans le processus d'import des paramètres de l'application, dont un qui permet à une application malveillante présente sur le même téléphone, sans demander aucune permission, d'importer silencieusement une configuration via des paramètres joints à un Intent, et ainsi de suivre la position et les trajets de l'utilisateur.
L'application Android de Wikipédia. L'agent a découvert une faille dans la logique de résolution des deep links : un attaquant peut construire un lien malveillant pour rediriger la victime vers une page falsifiée, en récupérer les cookies, puis finalement prendre le contrôle du compte et obtenir un jeton de connexion valable sur le long terme.
Stubbings écrit que l'équipe ne s'attendait pas à ce que le modèle comprenne aussi précisément le comportement des API liées à la sécurité dans des langages très divers, même sans recevoir de code source dans ce langage particulier ; le code de preuve de concept rédigé par l'agent ne nécessitait lui aussi que de très légères modifications pour fonctionner.
"LLMs are good at finding vulnerabilities but struggle at estimating severity."
Les grands modèles de langage sont doués pour trouver des vulnérabilités, mais peinent à en évaluer la gravité.
Ce qu'il ne sait pas encore faire
L'article est très franc sur les limites de l'outil. Le modèle signale souvent des problèmes de faible gravité, même quand le prompt demande explicitement de ne pas le faire ; face à des vulnérabilités déjà dotées de mesures d'atténuation, il évalue mal le risque réel ; il ne parvient pas à repérer les problèmes complexes de priorisation des flux de données ; et obtenir une preuve de concept fiable demande souvent plusieurs exécutions, parfois avec un débogueur branché ou des prompts supplémentaires. Conclusion : chaque découverte doit être vérifiée manuellement par un chercheur maîtrisant la sécurité mobile.
Côté coût, faire tourner l'outil nécessite une licence GitHub Copilot et consomme des requêtes vers des modèles premium. L'article prévient que les gros dépôts génèrent un grand nombre d'appels d'outils, avec une consommation de tokens non négligeable, sans préciser quel modèle a été utilisé.
Pour les développeurs en Chine
Les taskflows et les scripts sont open source sur GitHub, donc des équipes chinoises pourraient les adapter pour auditer leurs propres applications Android ; l'obstacle se situe du côté de la licence Copilot et de l'accès aux modèles étrangers. Le taskflow lui-même n'étant qu'un ensemble de prompts et d'orchestration d'étapes écrits en YAML, il pourrait en théorie être remplacé par des modèles chinois, mais aucune donnée comparative publique n'existe à ce jour sur son efficacité dans ce cas.
La fragmentation d'Android rend ce type d'outil encore plus utile sur le marché chinois. Les boutiques d'applications, les conteneurs de mini-programmes et les WebViews et ponts JavaScript des "super-applications" des différents fabricants de téléphones correspondent justement aux types de vulnérabilités couverts par cette liste. GitHub prévoit, comme prochaine étape, d'étendre les taskflows aux applications web et de bureau, et de les ouvrir aux contributions de la communauté.
Sources : blog officiel de GitHub, CocoLoop, dépôt open source de GitHub Security Lab ; le nombre de vulnérabilités, les téléchargements d'OsmAnd et la durée de chaque audit correspondent aux chiffres publiés par le blog de GitHub.