CodeQL 2.27.0 passe à ARM64, tandis que Java 9 et 10 approchent de la fin
L’annonce de GitHub datée du 9 septembre 2026 présente CodeQL 2.27.0 comme disponible avec une exécution native sur Linux ARM64. Elle précise dans la même publication que la prise en charge de Java 9 et 10 est désormais dépréciée avant son retrait en janvier 2027 et que l’archive CLI générique multiplateforme disparaîtra dans une version future.
La mise à jour sépare ainsi les adaptations immédiates des migrations à planifier. Les exécutants Linux ARM64 doivent télécharger un artefact propre à cette architecture, tandis que les pipelines fondés sur Java 9 ou 10 disposent encore d’une période de transition. Une analyse de CI/CD News relève que cette livraison supprime le recours à un binaire x86 exécuté par émulation sur les infrastructures ARM, sans apporter de mesure comparative de performances ou de coûts.
Linux ARM64 obtient ses propres artefacts
CodeQL traite désormais Linux ARM64, identifié par linux-arm64, comme une plateforme de premier rang. Les notes techniques de CodeQL 2.27.0 répertorient l’archive CLI codeql-linux-arm64.zip ainsi que les bundles codeql-bundle-linux-arm64.tar.gz et codeql-bundle-linux-arm64.tar.zst.
Les binaires ARM64 ne sont pas inclus dans les distributions combinées codeql.zip, codeql-bundle.tar.gz et codeql-bundle.tar.zst. Déplacer une analyse depuis un exécutant x64 vers une machine ARM64 sans modifier l’artefact téléchargé ne suffit donc pas : le pipeline doit sélectionner explicitement une distribution linux-arm64.
Le bénéfice confirmé porte sur la compatibilité native et la suppression d’une couche d’émulation éventuelle. La version ne permet pas de conclure à une accélération ou à une baisse des coûts par rapport à une infrastructure x64, faute de benchmark publié avec l’annonce.
Rust et les frameworks gagnent en couverture
CodeQL 2.27.0 ajoute la requête rust/command-line-injection, destinée à détecter les lignes de commande non contrôlées. Après la mise à niveau, un dépôt Rust peut donc produire de nouvelles alertes sans modification de son code, simplement parce que la couverture de sécurité comprend désormais cette catégorie de problème.
Deux requêtes Rust existantes évoluent aussi. rust/hard-coded-cryptographic-value doit générer moins de résultats situés à des emplacements très proches, tandis que rust/unused-variable ignore désormais les variables placées dans des fonctions contenant les macros standard todo!() ou unimplemented!().
Pour Java et Kotlin, la modélisation de Micronaut couvre notamment les contrôleurs HTTP, les points de terminaison WebSocket, l’injection de configuration, l’accès aux données, les annotations de sécurité et les appels de clients HTTP. Côté C#, la découverte des contrôleurs et actions ASP.NET Core MVC se rapproche du comportement à l’exécution, tandis que le suivi de contamination prend en charge la liaison des paramètres d’action OData.
D’autres ajustements peuvent modifier les résultats sans imposer de migration de plateforme. Les fonctions d’exécution de requêtes de PostgreSQL libpq sont reconnues comme des points sensibles à l’injection SQL en C et C++. Dans GitHub Actions, un contrôle fondé sur l’association de l’auteur n’est considéré comme protecteur que si le champ correspondant est réellement présent dans la charge utile de l’événement, ce qui peut faire apparaître des alertes supplémentaires.
Java 9 et 10 entrent dans leur dernière phase de prise en charge
La dépréciation vise la capacité de CodeQL à analyser Java 9 et 10, et non une disparition immédiate de ces environnements Java. Leur retrait est prévu en janvier 2027. Java 7 et 8 doivent rester pris en charge : il ne s’agit donc pas d’un abandon général des versions Java les plus anciennes.
Les pipelines concernés sont ceux qui créent ou utilisent des bases CodeQL à partir de projets construits avec Java 9 ou 10. Ils peuvent encore fonctionner pendant la période de dépréciation, mais ne pourront plus compter sur cette compatibilité après l’échéance annoncée. L’inventaire doit porter sur la version Java employée pendant la construction analysée, pas uniquement sur celle installée par défaut sur l’exécuteur.
L’archive générique codeql.zip suit un calendrier distinct. Elle est dépréciée et doit être retirée dans une version future, sans date plus précise à ce stade. La CLI affiche maintenant un avertissement lorsqu’elle est lancée depuis cette distribution ; la variable CODEQL_ALLOW_ALL_PLATFORMS_DIST=true masque le message, mais ne supprime pas la dépendance à une archive appelée à disparaître.
Les registres privés peuvent alimenter la configuration par défaut
La configuration par défaut de code scanning peut désormais exploiter les paramètres de registre privé d’une organisation lorsqu’elle récupère des requêtes ou des packs personnalisés. L’authentification peut viser un registre de conteneurs ou l’API GitHub, à condition qu’une configuration privée adaptée de type Git Source ou Docker Registry existe dans l’organisation.
Ce changement ne contraint pas les pipelines qui utilisent uniquement les packs publics. Il devient en revanche pertinent pour les organisations dont la configuration par défaut dépend de contenu CodeQL conservé dans des emplacements privés : les paramètres de registre et les droits associés doivent correspondre à la source effectivement interrogée.
Une checklist en deux calendriers
Les changements de CodeQL 2.27.0 ne constituent pas une rupture unique. Le choix d’un artefact ARM64 est nécessaire dès qu’une analyse passe sur cette architecture ; Java 9, Java 10 et l’archive générique restent utilisables pour le moment, mais sont désormais liés à une échéance ou à un avertissement.
- Dès le passage à Linux ARM64 : sélectionner l’archive CLI ou le bundle portant explicitement le suffixe linux-arm64.
- Pour les contenus privés : vérifier les configurations Git Source ou Docker Registry utilisées par la configuration par défaut de code scanning.
- Après la mise à niveau des dépôts Rust : distinguer les alertes de rust/command-line-injection des résultats produits par les requêtes déjà présentes.
- Avant janvier 2027 : identifier les analyses dont la construction dépend réellement de Java 9 ou 10 et préparer leur migration.
- Sans attendre une date de retrait : remplacer progressivement codeql.zip par un fichier codeql-PLATFORM.zip.
CodeQL 2.27.0 est déployé automatiquement auprès des utilisateurs de GitHub code scanning sur github.com. Une future version de GitHub Enterprise Server doit également recevoir ces fonctions, mais son numéro n’est pas encore précisé. Les inconnues restantes concernent donc la version qui supprimera définitivement codeql.zip et celle qui intégrera la mise à jour dans GHES ; le retrait de Java 9 et 10 reste fixé à janvier 2027.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.