CodeQL 2.27.2 sait analyser les regex en C++ et améliore l'analyse de Go, Rust et JavaScript

GitHub a publié CodeQL 2.27.2. Le principal changement de cette version est un parseur d'expressions régulières pour C++. En plus de cet ajout, l'analyse a été améliorée pour plusieurs langages, notamment Go, Rust et JavaScript. CodeQL est le moteur sur lequel repose le code scanning de GitHub : ce type de mise à jour influe donc directement sur les vulnérabilités et les erreurs que la plateforme détecte dans les dépôts. L'entrée du changelog est datée du 9 octobre 2026 et très courte : elle ne détaille ni requêtes, ni règles, ni correctifs précis.

Ce que l'on sait de la version

La formulation de GitHub est laconique : un parseur d'expressions régulières pour C++ a été ajouté, ainsi que des « améliorations de l'analyse » pour plusieurs langages. L'annonce ne précise rien langage par langage. Tout ce qui dépasse ces deux faits reste donc, pour l'instant, une hypothèse, et la liste exacte des modifications est à chercher dans les release notes complètes de CodeQL.

Principales données sur la version :

• version : CodeQL 2.27.2 ;
• date de publication : 9 octobre 2026 ;
• nouveauté : parseur d'expressions régulières pour C++ ;
• langages concernés : C++, Go, Rust, JavaScript (l'annonce parle de « plusieurs langages ») ;
• rôle : moteur d'analyse statique derrière le code scanning de GitHub.

Pourquoi un analyseur statique a besoin d'un parseur de regex

CodeQL représente le code sous la forme d'une base de données, interrogée par des requêtes écrites dans un langage dédié, QL. Pour qu'une requête puisse raisonner sur une chaîne qui est une expression régulière, l'analyseur doit comprendre sa structure : groupes, quantificateurs, alternatives, classes de caractères. Sans ce découpage, un littéral de chaîne n'est pour lui que du texte.

Le parseur fournit cette structure. C'est généralement sur elle que reposent des contrôles comme la détection de regex à backtracking catastrophique (ReDoS) ou celle de l'insertion non sécurisée de données utilisateur dans un motif. Pour JavaScript et plusieurs autres langages, cette infrastructure existe déjà dans CodeQL. L'arrivée d'un équivalent pour C++ comble une lacune dans un langage où les regex passent par la bibliothèque standard et par des paquets tiers. Une réserve s'impose : GitHub ne précise pas dans son annonce quelles requêtes utiliseront le nouveau parseur. Le lien avec ReDoS et les contrôles similaires est ici une déduction logique, pas un fait annoncé.

Et les autres langages ?

La mention de Go, Rust et JavaScript dans le titre indique que la mise à jour ne se limite pas à C++. Rust attire l'attention dans cette liste : la prise en charge du langage dans CodeQL est relativement récente, et la précision de la modélisation des bibliothèques et des flux de données y pèse directement sur le nombre de détections et de faux positifs. L'annonce ne dit pas ce qui a changé précisément ; il faudra donc évaluer l'effet à partir de ses propres résultats de scan.

Que vérifier après la mise à jour

Lorsque CodeQL s'exécute via le code scanning standard sur l'infrastructure hébergée par GitHub, la version est en général mise à jour côté plateforme. Si vous figez la version de CodeQL CLI ou utilisez vos propres pipelines, la mise à jour devra être faite manuellement.

Voici l'ordre d'action pratique :

• consultez les release notes de la version 2.27.2 et repérez les changements concernant les langages que vous utilisez ;
• lancez un scan sur une branche d'un dépôt de test et comparez le nombre et la nature des alertes avec la version précédente ;
• dans les projets C++ qui utilisent beaucoup les regex, examinez séparément les nouvelles détections : c'est là que les différences sont les plus probables ;
• ne désactivez pas automatiquement les alertes précédemment closes, mais vérifiez qu'elles n'ont pas disparu à cause de changements dans le modèle d'analyse ;
• si vous utilisez des requêtes QL personnalisées, assurez-vous qu'elles compilent sur la nouvelle version et que leur comportement ne change pas.

La version est modeste et très technique. Sa valeur réelle apparaîtra quand GitHub publiera la liste des changements, ou quand les équipes constateront la différence dans les rapports sur leur propre code.