Ce qui est confirmé
GitHub a annoncé le 4 août 2026 la version 2.26.2 de CodeQL, son moteur d’analyse statique utilisé par GitHub code scanning. Cette version ajoute la prise en charge de Swift 6.3.3 et de Kotlin jusqu’à la version 2.4.10. Elle fait aussi évoluer plusieurs requêtes de sécurité, notamment autour de l’injection de chemin, des redirections d’URL et de GitHub Actions, selon le changelog officiel.
Pour une équipe qui livre un produit SaaS, ce n’est pas une annonce à confondre avec une nouvelle fonctionnalité marketing. C’est une évolution de l’outillage qui examine le code. Le changement peut toutefois faire remonter des alertes différentes dans les dépôts concernés. Je te conseille donc de la lire comme un signal de revue, pas comme un résultat de sécurité automatique.
Ce qui est confirmé dans CodeQL 2.26.2
Fait. GitHub indique que CodeQL 2.26.2 analyse désormais les applications construites avec Swift 6.3.3. La version prend également en charge Kotlin jusqu’à 2.4.10 dans l’écosystème Java/Kotlin. Ces deux informations figurent dans l’annonce officielle du 4 août 2026.
Fait. GitHub présente CodeQL comme le moteur d’analyse statique derrière GitHub code scanning, destiné à identifier et corriger des problèmes de sécurité dans le code. Les nouveautés de cette version sont déployées automatiquement aux utilisateurs de GitHub code scanning sur github.com, d’après le changelog GitHub.
Fait. GitHub annonce aussi des améliorations de précision liées à l’injection de chemin, à la redirection d’URL et aux requêtes GitHub Actions. L’annonce ne fournit pas de volume d’alertes attendu. Elle ne permet donc pas de prévoir combien de résultats supplémentaires une organisation verra.
Voici la lecture la plus simple des changements documentés :
- Swift 6.3.3 est désormais dans le périmètre d’analyse annoncé.
- Kotlin est pris en charge jusqu’à 2.4.10.
- Certaines valeurs ou méthodes ne sont plus considérées comme des mécanismes de neutralisation complets.
- Des requêtes peuvent donc produire davantage de résultats.
- La syntaxe de liens ancienne syntaxe de liens à doubles crochets dans les messages d’alerte n’est plus analysée par CodeQL.
Si tu suis déjà les actualités du site, cette mise à jour rappelle une chose utile : une stack SaaS ne se limite pas au CRM, à l’email marketing ou à l’automation. La chaîne de livraison du produit mérite elle aussi une surveillance régulière.
Pourquoi certaines alertes peuvent évoluer
Fait. Pour C#, GitHub précise que System.Web.HttpRequest.RawUrl n’est plus traité comme un mécanisme de neutralisation par la requête cs/web/unvalidated-url-redirection. La raison donnée est que cette valeur contient une ligne de requête non normalisée. GitHub indique que ce changement peut générer davantage de résultats.
Fait. Pour Go, path/filepath.Rel n’est plus considéré comme une neutralisation pour go/path-injection et go/zipslip. GitHub signale là aussi qu’il peut y avoir plus de résultats. Pour Java et Kotlin, java.io.File.getName() n’est plus considéré comme une neutralisation complète pour java/path-injection, car il ne supprime pas une composante .. dans un chemin.
Concrètement, l’outil ne dit pas qu’une alerte nouvelle correspond forcément à une vulnérabilité exploitable. Il dit qu’une hypothèse de sûreté précédente a été retirée ou resserrée. C’est une nuance importante pour éviter deux erreurs opposées : ignorer les résultats nouveaux, ou les traiter immédiatement comme des incidents confirmés.
Je procéderais par triage. D’abord, regarde si le dépôt utilise les langages et les mécanismes concernés. Ensuite, reproduis le chemin de données depuis l’entrée contrôlée par un utilisateur jusqu’à la fonction signalée. Enfin, documente la décision de correction ou de non-exploitabilité. Ce travail rejoint les bases que je détaille dans mon guide pour automatiser son business, même si la sécurité ne doit pas devenir une automation aveugle.
GitHub Actions : attention aux checkouts non fiables
Fait. GitHub a modifié la logique EnvironmentCheck afin qu’elle ne protège que des scénarios sans condition de concurrence de type TOCTOU. Selon l’annonce, cette évolution fait remonter davantage de résultats dans les requêtes liées aux checkouts non fiables.
Un checkout non fiable dans une automatisation CI mérite une lecture attentive, car une pull request peut déclencher des étapes qui consomment du code ou des paramètres externes. C’est une analyse de risque générale, pas une affirmation qu’un dépôt précis est exposé. Le changelog ne publie ni liste de dépôts affectés, ni correctif universel.
Pourquoi c’est important
Pour les équipes no-code et low-code, le lien est indirect mais réel. Ton workflow Make, Zapier ou n8n n’exécute pas CodeQL à ta place. En revanche, dès qu’un produit SaaS s’appuie sur un dépôt, une intégration GitHub ou des scripts internes, la sécurité des automatisations fait partie de l’exploitation. C’est le même réflexe que lorsque tu choisis un outil de gestion de projet : identifier le propriétaire, le déclencheur et la trace laissée par chaque étape.
Une modification de suite qui peut compter
Fait. GitHub retire la requête cs/useless-assignment-to-local de la suite code-quality. Elle reste présente dans la suite code-quality-extended. C’est un changement de classification, pas l’annonce de la disparition complète de la requête.
Fait. Pour C/C++, la requête cpp/new-free-mismatch utilise désormais l’étiquette external/cwe/cwe-762 au lieu de external/cwe/cwe-401. GitHub explique que cette étiquette correspond mieux au comportement de la requête.
En pratique, ces détails comptent surtout si tu pilotes un dashboard de qualité, si tu compares les résultats après une mise à jour, ou si tu maintiens des règles internes autour de CodeQL. Une variation dans le nombre d’alertes peut venir d’une meilleure détection, d’un changement de suite, ou d’un vrai changement du code. Sans ces trois vérifications, un indicateur isolé peut conduire à une mauvaise décision.
Cela vaut aussi pour les métriques marketing. Une variation de leads dans un CRM ne suffit pas à expliquer le résultat. Il faut remonter à la source, au déclencheur et à la définition exacte de la métrique. Pour les alertes CodeQL, la version de l’analyseur devient une partie de ce contexte.
La rupture à anticiper pour les auteurs de requêtes
Fait. CodeQL ne traite plus les liens au format ancienne syntaxe de liens à doubles crochets dans les messages d’alerte. GitHub qualifie cette fonction de fonctionnalité historique non documentée. L’alternative indiquée est l’utilisation de paires de placeholders $@.
Si ton équipe écrit des requêtes CodeQL personnalisées, ce point mérite un contrôle ciblé avant toute mise à jour de contenu ou de dépendance. Le changelog ne donne pas d’outil de migration automatique. Il ne détaille pas non plus le nombre de requêtes susceptibles d’utiliser cette syntaxe. Il faut donc chercher cette construction dans les requêtes que tu maintiens, puis tester l’affichage des messages.
Je ne confondrais pas ce travail avec un projet de refonte. Il s’agit d’abord d’un inventaire : quelles requêtes maison existent, quels messages comportent des liens, et quel format est attendu après mise à jour. Cette discipline d’inventaire est aussi pertinente lorsqu’on construit une application no-code ou une stack de contenus.
Ce que ça change pour toi
Analyse. Si tu utilises GitHub code scanning sur github.com, la nouvelle version est annoncée comme déployée automatiquement. Le bon réflexe consiste à surveiller les résultats après le déploiement, surtout pour les projets en C#, Go, Java, Kotlin, Swift, C/C++ et les workflows GitHub Actions concernés.
Analyse. Si tu utilises GitHub Enterprise Server, GitHub précise que ces fonctions arriveront dans une future version de GHES. La date de disponibilité n’est pas donnée dans la source. Si tu restes sur une version plus ancienne de GHES, GitHub indique que tu peux mettre à niveau ta version de CodeQL manuellement. Avant toute action, vérifie toutefois la documentation correspondant à ta version d’entreprise.
Analyse. Pour un entrepreneur, le sujet est moins spectaculaire qu’un nouveau modèle d’IA. Pourtant, un SaaS repose sur la confiance : données clients, formulaires, liens de connexion, intégrations et opérations de déploiement. Réserver un créneau de revue après l’évolution d’un scanner est souvent plus utile que multiplier les outils sans responsable clair.
Si ton acquisition dépend de contenus et de processus techniques, je te renvoie aussi à mon article sur Google AI Overviews en France. Les canaux changent, mais la méthode reste la même : séparer ce qui est annoncé, ce qui est mesuré et ce qui doit être contrôlé.
Ce qui reste inconnu
Fait. L’annonce officielle ne communique ni nombre de nouveaux résultats attendus, ni liste de projets affectés, ni calendrier précis pour une version GHES intégrant ces changements. Elle ne publie pas non plus de prix, de plan tarifaire ou de condition commerciale.
Ce que cela change
Cette absence d’information ne signifie pas qu’il n’y aura aucun effet dans ton environnement. Elle signifie simplement qu’on ne peut pas attribuer à l’avance un impact précis à cette mise à jour. Pour un suivi sérieux, note la date de bascule observée, la version utilisée, les alertes apparues et leur statut de validation.
Mon avis
Opinion. Je trouve que les mises à jour de scanners méritent plus d’attention dans les petites équipes SaaS. Elles ne remplacent pas une revue humaine, mais elles peuvent remettre en question des suppositions techniques anciennes. Selon moi, la meilleure réponse n’est pas d’ajouter un dashboard de plus. C’est d’attribuer clairement la revue des nouvelles alertes à une personne et de garder une trace de la décision.
Pour organiser cette veille avec le reste de ton marketing et de tes opérations, tu peux aussi parcourir mes guides et les vidéos. Sur les sujets de croissance et de visibilité, mon agence AskOptimize intervient séparément de ce site éditorial.
FAQ
CodeQL 2.26.2 prend-il en charge Swift 6.3.3 ?
Oui. GitHub annonce la prise en charge de l’analyse des applications construites avec Swift 6.3.3 dans CodeQL 2.26.2, selon le changelog officiel.
Jusqu’à quelle version Kotlin CodeQL 2.26.2 est-il compatible ?
GitHub indique une prise en charge de Kotlin jusqu’à la version 2.4.10. L’annonce ne fournit pas d’information supplémentaire sur les versions ultérieures.
Pourquoi de nouvelles alertes CodeQL peuvent-elles apparaître ?
GitHub précise que certains mécanismes ne sont plus considérés comme des neutralisations complètes. Les requêtes concernées peuvent donc renvoyer davantage de résultats, notamment autour des chemins, des redirections d’URL et de GitHub Actions.
Que change CodeQL 2.26.2 pour GitHub Actions ?
GitHub a modifié EnvironmentCheck afin de ne protéger que les scénarios sans TOCTOU. L’annonce indique que cela fait remonter davantage de résultats pour les requêtes sur les checkouts non fiables.
Faut-il mettre à jour CodeQL manuellement sur GitHub.com ?
Non, GitHub indique que chaque nouvelle version de CodeQL est déployée automatiquement aux utilisateurs de GitHub code scanning sur github.com. Pour une ancienne version de GHES, GitHub indique qu’une mise à jour manuelle de CodeQL est possible.
Information & avertissement
Cet article est une information éditoriale fondée sur le changelog officiel cité. Il ne contient aucune offre validée ni lien affilié fourni dans le dossier de sources. Je ne peux pas évaluer la sécurité d’un dépôt particulier sans audit technique.
Sources et méthode
Les informations ont été vérifiées à partir des sources ci-dessous.
Les faits confirmés sont distingués des analyses et des limites encore ouvertes.
