CodeQL ne peut pas tracer les builds Xcode 27 ni analyser Swift 6.4

GitHub a annoncé le 19 octobre 2026 que CodeQL, son moteur d'analyse de code, ne peut pas tracer les builds réalisés avec Xcode 27 et ne peut analyser du code Swift 6.4 sur aucune plateforme. Pour les équipes iOS et Mac qui lancent des analyses de sécurité dans leur pipeline de build, passer aux outils les plus récents d'Apple revient désormais à perdre une partie de ces analyses, jusqu'à ce que GitHub en livre la prise en charge.

Ce que GitHub a annoncé

CodeQL est l'outil derrière le code scanning de GitHub. Il transforme le code source d'un projet en base de données, puis y exécute des requêtes pour trouver des failles de sécurité. Pour les langages compilés, il construit généralement cette base en « traçant » le build : il observe le compilateur pendant son exécution et enregistre chaque fichier au moment où il est compilé.

C'est ce traçage qui ne fonctionne plus. À partir de macOS 27 et Xcode 27, Apple n'inclut plus de code Intel (x86_64) dans certains fichiers système dont CodeQL dépend, selon le changelog de GitHub. Ces fichiers sont des binaires et des bibliothèques que CodeQL utilise pour tracer les builds. L'avis le dit clairement : « CodeQL ne peut pas prendre en charge les scans tracés sur ces versions, ni analyser Swift 6.4. »

Configuration	Ce que dit GitHub
Xcode 27 installé	L'extraction tracée n'est pas disponible pour C/C++, C#, Go, Java, Kotlin ou Swift
macOS 27	L'extraction tracée peut ne pas être disponible pour les six mêmes langages
Swift 6.4	Non pris en charge, quelle que soit la plateforme
Mac à processeur Intel	Prise en charge par CodeQL dépréciée à la mi-décembre 2026

Le changelog ne donne aucune date pour la prise en charge de Swift 6.4.

Pourquoi passer à Xcode 27 entraîne Swift 6.4

Le problème de Swift est difficile à éviter pour une équipe qui met ses outils à jour. La page des exigences d'Xcode d'Apple liste trois versions actuelles : Xcode 27, Xcode 27.1 et la bêta 3 d'Xcode 27.2. Toutes trois embarquent le compilateur Swift 6.4. Toutes trois exigent un Mac sous macOS Tahoe 26.6 ou une version ultérieure.

Il n'existe donc aucune version d'Xcode 27 qui conserve un compilateur Swift plus ancien. Passer à Xcode 27, c'est passer à Swift 6.4, la version qui a apporté le defer asynchrone et fait de Swift Build l'outil par défaut. C'est aussi perdre l'analyse Swift de CodeQL. Cela compte pour les apps qui ont besoin d'Xcode 27 lui-même. La release candidate d'Xcode 27.1, par exemple, est ce qui a ouvert les soumissions à l'App Store pour les apps iPhone Duo.

Les solutions de contournement proposées par GitHub

L'avis de GitHub liste trois façons de maintenir les analyses :

• S'en tenir aux outils précédents. Les workflows qui analysent du Swift, ou qui reposent sur des builds tracés, doivent tourner sous macOS 26 ou antérieur, avec Xcode 26 ou antérieur.
• Figer le runner et la chaîne d'outils. Dans GitHub Actions, définissez explicitement l'image du runner et la version de la chaîne d'outils, pour qu'une mise à jour d'image ne puisse pas basculer une analyse sur Xcode 27 sans prévenir.
• Éviter le traçage quand c'est possible. Pour C/C++, C# et Java, utilisez le mode de build « none » de CodeQL. Dans ce mode, CodeQL lit directement les fichiers source au lieu d'observer un build, donc l'absence du code Intel ne pose pas de problème.

L'avis ne propose le mode de build « none » que pour ces trois langages. Pour Swift, son seul conseil est de rester sur Xcode 26 ou antérieur.

Ce que cela signifie pour les développeurs

Le risque, ici, c'est une analyse qui continue de tourner mais cesse discrètement de couvrir votre code. Quelques vérifications valent la peine cette semaine :

• Vérifiez sur quoi tourne vraiment votre job d'analyse. Si un workflow CodeQL utilise une étiquette de runner flottante plutôt qu'une image figée, vérifiez quelles versions de macOS et d'Xcode il obtient aujourd'hui. Puis figez-les, comme le recommande GitHub.
• Lisez les logs d'analyse, pas seulement le résultat. Une coche verte signifie que le job s'est terminé. Elle ne prouve pas que les fichiers Swift ont été analysés. Regardez l'étape d'extraction dans le log et vérifiez que vos sources Swift y figurent.
• Séparez le build de l'analyse. Les équipes qui doivent livrer avec Xcode 27 peuvent continuer à y compiler leurs versions. Elles peuvent lancer le job CodeQL à part, sur un runner figé en macOS 26 et Xcode 26. Cela ne fonctionne que tant que le code compile encore avec Xcode 26, donc adopter des fonctionnalités propres à Swift 6.4 y met fin.
• Préparez dès maintenant la fin des runners Intel. Les runners Mac Intel auto-hébergés perdent la prise en charge de CodeQL à la mi-décembre 2026. Prévoyez un budget pour des machines Apple silicon d'ici là.
• Surveillez les prochaines notes de version de CodeQL. La version 2.27.1 a ajouté une requête C++ et la lecture des fichiers de verrouillage d'Actions. La prise en charge de Swift 6.4 arriverait de la même façon, et c'est à ce moment-là qu'il faudra libérer les versions figées.