L'agent de sécurité IA de GitHub commence à dénicher des vulnérabilités à grande échelle. Le 28 septembre, le GitHub Security Lab a annoncé sur son blog officiel que des chercheurs auditant des applications Android avec son agent de sécurité IA open source ont découvert et signalé 24 vulnérabilités — dont deux cas à haute sévérité déjà divulgués publiquement : l'un permet à n'importe quelle application de suivre la localisation précise d'un utilisateur, l'autre permet de prendre totalement le contrôle d'un compte Wikipedia.
L'outil s'appelle seclab-taskflow-agent, et ses flux d'audit seclab-taskflows sont entièrement open source. L'idée n'est pas de jeter toute une base de code à un grand modèle en croisant les doigts, mais de découper l'audit en étapes incrémentielles via des prompts YAML, et d'encapsuler le « comment auditer » dans des taskflows réutilisables. Pour Android, deux taskflows dédiés ont été ajoutés : gather_mobile_entry_point_info repère les points d'entrée du code par lesquels des données contrôlées par un attaquant peuvent transiter, en séparant les surfaces d'attaque mobiles des autres ; classify_application_local liste ensuite, par type de point d'entrée, les classes de vulnérabilités courantes à vérifier — par exemple, face à un point d'entrée basé sur les intents, il rappelle au modèle de chercher des problèmes typiquement mobiles comme le confused deputy ou les broadcasts non sécurisés.
L'exécution est simple : ouvrir un Codespace sur le dépôt seclab-taskflows et lancer ./scripts/audit/run_mobile.sh contre le dépôt cible ; un dépôt de taille moyenne est traité en une à deux heures, les résultats étant écrits dans une base SQLite — il suffit de repérer les lignes cochées dans la colonne has_vulnerability. Deux conditions d'accès : une licence GitHub Copilot est requise, et l'audit consomme un grand nombre de requêtes modèle premium, donc la facture en tokens n'est pas anodine.
Deux cas à haute sévérité déjà divulgués
Le premier est OsmAnd, une application de navigation open source téléchargée plus de 10 millions de fois. Sa MapActivity est exportée, si bien que n'importe quelle application peut lui envoyer des intents ; et le gestionnaire d'import des paramètres fait aveuglément confiance aux extras d'intent comme silent_import ou replace. Une application malveillante sans aucune permission peut donc réécrire silencieusement les paramètres d'OsmAnd et substituer les URL des tuiles cartographiques par un domaine d'attaquant : chaque tuile chargée par l'utilisateur envoie ses coordonnées exactes au serveur de l'attaquant — une fuite de localisation en temps réel — et la même faille expose l'origine et la destination de chaque itinéraire, sans que l'utilisateur ne remarque rien.
Le second est l'application Android Wikipedia, où deux bogues logiques s'enchaînent en prise de contrôle de compte. L'application enregistre un deeplink wikipedia://, mais son analyseur de nom d'hôte ne vérifie que le suffixe du domaine — des domaines comme evil-wikipedia.org passent la validation et attirent l'utilisateur vers une page d'attaquant ; dans le même temps, la vérification de domaine du gestionnaire de cookies ne compare elle aussi que les suffixes, permettant à la page d'attaquant de récupérer les cookies de session longue durée de Wikipedia — un seul cookie vaut pour tous les projets Wikimedia, nom d'utilisateur et jetons longue durée inclus.
Les LLM trouvent les vulnérabilités mais ne savent pas en juger la gravité
Le blog reconnaît franchement les limites de la méthode : les LLM excellent à découvrir des vulnérabilités — y compris des bogues logiques que les humains manquent facilement — mais estiment mal leur sévérité. Ils signalent couramment des problèmes à faible impact et jugent mal les cas comportant des facteurs atténuants, comme les traversées de chemin limitées au stockage externe. Chaque découverte nécessite toujours la relecture d'un chercheur qui comprend la sécurité mobile, et les cas sérieux exigent que le modèle construise réellement une preuve de concept pour confirmer l'exploitabilité.
L'enjeu n'est pas le chiffre 24, mais le fait qu'une méthodologie d'audit devient pour la première fois un pipeline open source et reproductible. Le Security Lab avait déjà ouvert le code d'un taskflow de fuzzing IA pour le C/C++ (indiquez l'adresse d'un dépôt, les vulnérabilités sont trouvées automatiquement) ; cette version comble le vide côté mobile. Pour les développeurs ordinaires, la valeur pratique est directe : pas besoin d'attendre l'équipe sécurité — lancez-le contre votre propre dépôt et ramassez d'abord une série de vrais problèmes.
