Le 19 août 2026, GitHub a publié CodeQL 2.26.3. Cette mise à jour concerne l’analyse de code utilisée par GitHub Code Scanning. Elle apporte des changements sur GitHub Actions, JavaScript, TypeScript, Vue, Sails, C/C++, Ruby et certaines requêtes de sécurité.
Le point important est simple : CodeQL 2.26.3 peut modifier les alertes visibles dans tes dépôts sans que ton application ait changé. GitHub annonce à la fois de nouveaux modèles de flux de données, des corrections de précision et la suppression d’un module utilisé par certaines requêtes personnalisées. Si tu pilotes des projets avec une stack SaaS, no-code ou low-code complétée par du code, cette actualité mérite donc une vérification méthodique.
Ce que GitHub confirme dans CodeQL 2.26.3
Fait. GitHub présente CodeQL comme le moteur d’analyse statique derrière GitHub Code Scanning. Son rôle est d’aider à trouver puis à corriger des problèmes de sécurité dans le code. La publication officielle de GitHub associe explicitement cette fonction à la version 2.26.3.
Fait. Pour GitHub Actions, l’analyse reconnaît désormais les données non fiables dans github.event.merge_group lorsqu’un workflow est déclenché par l’événement merge_group. GitHub indique aussi plusieurs ajustements sur des requêtes existantes, notamment celles qui concernent les sorties manipulées, les caches, les checkouts non fiables, l’injection par variables d’environnement et la classification de l’événement schedule.
Fait. Une modification incompatible est annoncée. Le module codeql.actions.security.SelfHostedQuery est supprimé. GitHub explique que les labels de runners ne permettent pas de distinguer de manière fiable un runner auto-hébergé d’un runner géré. Les équipes qui utilisent ce module dans des requêtes personnalisées doivent donc les mettre à jour.
Tu peux suivre les autres changements liés à l’écosystème GitHub dans mes actualités. Elles permettent de replacer une évolution ponctuelle dans une veille plus large sur les outils que tu utilises au quotidien.
JavaScript, TypeScript et Vue gagnent des modèles de flux
Fait. CodeQL 2.26.3 permet aux modèles personnalisés JavaScript et TypeScript de référencer des fichiers précis avec un nom de package sous la forme file:<path>. GitHub précise que cela sert à définir des sources et des sinks à partir des exports publics d’un fichier.
Ce point est technique, mais il compte pour les équipes qui maintiennent leur propre modélisation. Une application marketing peut regrouper des composants, des connecteurs ou des transformations de données dans des fichiers ciblés. La possibilité de les désigner plus finement peut rendre un modèle personnalisé plus proche de la structure réelle du projet. C’est une analyse de la fonctionnalité annoncée, pas une promesse de couverture automatique.
Fait. GitHub ajoute des modèles de flux pour les helpers de l’API Composition de Vue : ref, shallowRef, toRef, reactive et computed. CodeQL reconnaît également useRoute() de Vue Router comme une source distante côté client. GitHub cite les membres query, params, path, fullPath et hash.
Fait. Pour Sails Action2, les propriétés inputs déclarées dans les fichiers de contrôleurs deviennent des sources de flux distantes. GitHub indique que cela peut améliorer les résultats de requêtes telles que js/path-injection.
Fait. Les requêtes utilisant le modèle de menace de réponse suivent désormais les données de réponse client encapsulées dans une promesse jusqu’aux valeurs de résolution. GitHub indique que cela peut améliorer des requêtes comme js/xss.
Les changements annoncés pour GitHub Actions
Fait. GitHub a amélioré la précision de la requête actions/output-clobbering/high. Elle ne doit plus signaler de simples filtres de chemin jq lorsque leur sortie reste encodée en JSON. GitHub mentionne aussi un correctif de performance lié à une entrée d’expression régulière non échappée dans cette requête.
Fait. Les requêtes actions/cache-poisoning/poisonable-step et actions/untrusted-checkout/critical démarrent désormais les chemins aux expressions qui contrôlent les checkouts non fiables. GitHub présente ce changement comme un moyen de rendre les alertes plus faciles à suivre.
Fait. La version corrige la classification de l’événement schedule lors de la détermination du déclenchement externe possible d’un workflow. La requête actions/envvar-injection/critical exige maintenant que la source non fiable et le contexte privilégié viennent du même événement déclencheur. Elle ne considère plus les labels de tête de pull request comme susceptibles d’injection, car GitHub indique qu’ils ne peuvent pas contenir de retours à la ligne.
Fait. Les requêtes actions/cache-poisoning/code-injection, actions/cache-poisoning/direct-cache et actions/cache-poisoning/poisonable-step prennent désormais en compte l’accès en lecture seule au cache sur les déclencheurs à faible confiance. La note de publication constitue la source disponible pour ce périmètre précis.
Pour compléter ta lecture sur les agents et les extensions, consulte mon article sur les plugins d’agents GitHub. Il s’agit d’un lien de contexte interne, pas d’une confirmation supplémentaire des changements de CodeQL.
C/C++ et Ruby : des effets potentiels sur les résultats
Fait. GitHub ajoute des modèles de sources de flux pour RegQueryValue et des fonctions associées du header Windows winreg.h en C/C++. Le changelog ne chiffre ni le nombre d’alertes concernées ni le gain de couverture attendu.
Fait. En Ruby, GitHub retire les entrées de bibliothèque des gems vendorisées de l’ensemble des sources de taint. Selon le changelog, cette modification réduit les faux positifs pour plusieurs requêtes lorsque le vendoring est utilisé.
Concrètement, un changement de moteur d’analyse ne signifie pas automatiquement qu’un dépôt devient plus ou moins sûr. Il signifie que les règles, leurs sources ou leurs chemins peuvent évoluer. Les alertes nouvelles doivent être triées. Les alertes disparues doivent être comprises avant d’être considérées comme résolues. Cette prudence relève de mon analyse opérationnelle à partir des modifications documentées.
Si tu structures aussi tes processus autour d’outils métier, mon guide sur la gestion de projet et ses méthodes peut t’aider à documenter qui examine les alertes, dans quel délai et avec quelle trace de décision.
Ce qui reste inconnu
Fait. La publication de GitHub ne fournit pas, dans les informations disponibles ici, de volume d’alertes attendues, de liste de dépôts touchés, de calendrier de déploiement par organisation ni de procédure de migration détaillée pour le module supprimé. Elle annonce bien qu’une mise à jour est nécessaire pour les requêtes personnalisées qui s’appuient sur SelfHostedQuery.
Analyse. Ne déduis pas d’un intitulé « améliore » un résultat identique sur tous les projets. Le résultat dépend des langages, des frameworks, des workflows, des requêtes actives et des modèles personnalisés présents dans ton dépôt. Aucun de ces éléments n’est décrit pour ton environnement dans la source fournie.
Analyse. La bonne question n’est donc pas « faut-il s’alarmer ? ». La bonne question est « quelles alertes et quelles requêtes changent dans mon périmètre ? ». Cette formulation évite de transformer une annonce produit en diagnostic de sécurité.
Ce que ça change pour toi
Si tu utilises GitHub Actions avec Code Scanning, commence par identifier les workflows déclenchés par merge_group, schedule, les pull requests et les événements qui touchent aux caches ou aux checkouts. C’est une recommandation de méthode. Les événements et les requêtes cités sont ceux que GitHub mentionne dans son changelog.
Ensuite, regarde si ton équipe maintient des requêtes CodeQL personnalisées. La suppression de codeql.actions.security.SelfHostedQuery est le point qui appelle une action explicite dans ce cas. Ne remplace pas le module par une hypothèse sur les labels des runners. GitHub justifie justement sa suppression par le manque de fiabilité de cette distinction.
Pour les applications Vue, compare les alertes liées aux données de route avant et après la mise à jour. Les champs reconnus par GitHub incluent query, params, path, fullPath et hash. Pour les applications JavaScript ou TypeScript avec des modèles maison, examine aussi les références de fichiers sous la forme file:<path>.
Je te conseille de consigner le contexte de chaque alerte modifiée : requête, workflow ou fichier concerné, décision prise et personne qui a validé. Cette discipline reste utile même hors sécurité. Elle rejoint la logique de l’automatisation de son business : un workflow utile doit rester observable, compréhensible et révisable.
Si ta stack contient plusieurs outils, évite de confondre une alerte de code avec un problème de CRM, d’email marketing ou de funnel. GitHub décrit ici CodeQL et GitHub Actions. La source ne documente ni Make, ni Zapier, ni n8n, ni un outil SaaS tiers. Cette limite est importante pour décider qui doit enquêter.
Tu peux aussi rapprocher ce sujet de mon décryptage de l’intégration de l’IA en entreprise. Dans les deux cas, l’outil ne remplace pas le processus de vérification. Il ajoute des signaux qu’il faut savoir interpréter.
Pour un cadrage plus large de tes ressources et de mes contenus transverses, retrouve aussi mon hub principal. Ce lien sert de navigation dans l’écosystème éditorial.
Mon avis
Opinion. Je trouve la suppression du module sur les runners plus utile qu’une distinction fragile conservée par habitude. Un signal de sécurité doit être interprétable avant d’être automatisé dans un workflow d’équipe. Selon moi, la priorité est de vérifier les requêtes personnalisées, puis de relire les alertes GitHub Actions qui changent après la mise à jour. Je ne traiterais pas ce changelog comme une preuve qu’un projet est sécurisé ou vulnérable.
FAQ
Que change CodeQL 2.26.3 pour GitHub Actions ?
Fait. GitHub annonce la reconnaissance de données non fiables dans github.event.merge_group et des ajustements sur plusieurs requêtes GitHub Actions, dont celles liées aux caches, aux checkouts, aux variables d’environnement et à schedule. Consulte le changelog officiel pour le détail.
Faut-il modifier une requête qui utilise SelfHostedQuery ?
Fait. Oui, GitHub indique qu’il faut mettre à jour les requêtes personnalisées qui reposent sur codeql.actions.security.SelfHostedQuery, car ce module est supprimé dans CodeQL 2.26.3.
CodeQL 2.26.3 améliore-t-il l’analyse d’une application Vue ?
Fait. GitHub ajoute des modèles pour plusieurs helpers de l’API Composition et reconnaît useRoute() de Vue Router comme source distante côté client. Analyse. L’effet concret dépend ensuite du code et des requêtes présents dans ton dépôt.
Quels champs Vue Router sont reconnus par CodeQL ?
Fait. GitHub cite query, params, path, fullPath et hash parmi les membres de useRoute() reconnus comme flux distants côté client.
Comment suivre les autres actualités GitHub et IA ?
Tu peux parcourir la rubrique actualités et lire mon article sur Gemini dans GitHub Copilot. Ces liens internes servent à poursuivre ta veille. Ils ne remplacent pas la source officielle de cette mise à jour.
Information & avertissement
Cet article est une lecture éditoriale d’une note de publication officielle de GitHub. Il ne constitue ni un audit de sécurité, ni un diagnostic de ton dépôt, ni une garantie sur les alertes de Code Scanning. Vérifie les changements dans ton environnement avant toute décision technique. Aucune offre commerciale ni aucun lien affilié n’est présenté dans cet article.
