Analyse du code CodeQL pour les langages compilés

À propos du Workflow d’analyse CodeQL et des langages compilés

L’Code scanning fonctionne en exécutant des requêtes sur une ou plusieurs bases de données CodeQL. Chaque base de données contient une représentation du code dans un langage unique au sein de votre référentiel. Pour les langages compilés C/C++, C#, Go, Java, Kotlin et Swift, le processus de remplissage de cette base de données implique la génération du code et l’extraction de données.

Si vous activez l’installation par défaut, l’action autobuild sera utilisée pour générer votre code, dans le cadre de votre configuration automatique de Workflow d’analyse CodeQL. Si vous activez l'installation de configuration avancée, le flux de base Workflow d’analyse CodeQL utilise autobuild. Sinon, vous pouvez désactiver autobuild et spécifier à la place des commandes de build explicites pour analyser uniquement les fichiers générés par ces commandes personnalisées.

Pour plus d’informations sur les langages, bibliothèques et cadres pris en charge dans la dernière version de CodeQL, consultez Langages et cadres pris en charge dans la documentation CodeQL. Pour plus d’informations sur la configuration requise pour l’exécution de la dernière version de CodeQL, consultez Configuration requise dans la documentation CodeQL.

À propos de la génération automatique pour CodeQL

L’action CodeQL utilise autobuild pour analyser les langages compilés dans les cas suivants.

• La configuration par défaut est activée.
• La configuration avancée est activée et le workflow a une étape de génération automatique pour le langage à l’aide de l’action autobuild (github/codeql-action/autobuild@v2).

Le flux de travail de base Workflow d’analyse CodeQL utilise l'action autobuild pour construire votre code.

    # Initializes the CodeQL tools for scanning.
    - name: Initialize CodeQL
      uses: github/codeql-action/init@v2
      with:
        languages: ${{ matrix.language }}

    - name: Autobuild
      uses: github/codeql-action/autobuild@v2

À propos de la spécification manuelle des étapes de génération

Vous ne pouvez spécifier que les étapes de build manuelles si vous avez activé l’installation avancée, consultez Configuration de la configuration par défaut pour l’analyse du code.

En cas d’échec de autobuild ou si vous souhaitez analyser un ensemble différent de fichiers source générés par le processus autobuild, vous devez supprimez ou commentez l’étape de génération automatique dans le workflow. Supprimez ensuite les marques de commentaire de l’étape run et spécifiez manuellement le processus de génération à utiliser. Pour C/C++, C#, Go, Java, Kotlin et Swift, CodeQL va analyser le code source généré par vos étapes de génération spécifiées. Pour plus d’informations sur la modification du fichier de flux de travail, consultez Personnalisation de votre configuration avancée pour l’analyse de code.

    # Autobuild attempts to build any compiled languages.
    # - name: Autobuild
    #  uses: github/codeql-action/autobuild@v2

Spécification des commandes de build

Lorsque la génération manuelle est activée, supprimez les marques de commentaire de l’étape run dans le workflow et ajoutez des commandes de génération adaptées à votre référentiel. L’étape run exécute des programmes en ligne de commande avec le shell du système d’exploitation. Vous pouvez modifier ces commandes et ajouter d’autres commandes pour personnaliser le processus de build.

- run: |
    make bootstrap
    make release

Pour plus d’informations sur le mot clé run, consultez Workflow syntax for GitHub Actions.

Spécification de commandes de génération pour plusieurs langages

Pour les référentiels contenant plusieurs langages compilés, vous pouvez spécifier des commandes de génération propres à un langage. Par exemple, si votre référentiel contient C/C++, C# et Java, vous pouvez fournir des étapes de génération manuelles pour un langage (ici Java). Cela spécifie les étapes de génération pour Java tout en continuant à utiliser autobuild pour C/C++ et C#.

- if: matrix.language == 'cpp' || matrix.language == 'csharp'
  name: Autobuild
  uses: github/codeql-action/autobuild@v2
- if: matrix.language == 'java'
  name: Build Java
  run: |
    make bootstrap
    make release

Pour plus d’informations sur le conditionnel if, consultez Workflow syntax for GitHub Actions.

Si vous avez ajouté des étapes de génération manuelles pour les langages compilés et que l’code scanning ne fonctionne toujours pas sur votre dépôt, contactez le votre administrateur de site.

Étapes de génération automatique pour les langages compilés

Si vous utilisez des exécuteurs auto-hébergés pour GitHub Actions, vous devrez peut-être installer des logiciels supplémentaires pour utiliser le processus autobuild. En outre, si votre dépôt nécessite une version spécifique d’un outil de génération, vous devrez peut-être l’installer manuellement. Pour les exécuteurs auto-hébergés, vous devez installer des dépendances directement dans les exécuteurs eux-mêmes. Nous fournissons des exemples de dépendances courantes pour C/C++, C# et Java dans chacune des sections autobuild de cet article pour ces langages. Pour plus d’informations, consultez À propos des exécuteurs auto-hébergés.

• Génération de C/C++
• Génération de C#
• Génération de Go
• Génération de Java et Kotlin
• Génération de Swift

Génération de C/C++

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux
Système de build	Windows : scripts MSbuild et de build Linux et macOS : Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild et scripts de build

Le comportement de l’étape autobuild varie en fonction du système d’exploitation sur lequel l’extraction s’exécute.

Autodétection Windows

Sur Windows, l’étape autobuild tente de détecter automatiquement une méthode de génération appropriée pour C/C++ en utilisant l’approche suivante :

1. Appeler MSBuild.exe sur le fichier solution (.sln) ou projet (.vcxproj) le plus proche de la racine. Si autobuild détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.
2. Appeler un script qui ressemble à un script de build : build.bat, build.cmd et build.exe (dans cet ordre).

Autodétection Linux et macOS

Sur Linux et macOS, l’étape autobuild passe en revue les fichiers présents dans le dépôt pour déterminer le système de build utilisé :

1. Rechercher un système de build dans le répertoire racine.
2. Si aucun répertoire n’est trouvé, rechercher un répertoire unique avec un système de build pour C/C++.
3. Exécuter une commande appropriée pour configurer le système.

Conditions requises pour l’exécuteur pour C/C++

Sur les exécuteurs Ubuntu Linux, il se peut qu’autobuild tente d’installer automatiquement les dépendances requises par les étapes de configuration et de génération détectées. Par défaut, ce comportement est activé sur les exécuteurs hébergés sur GitHub et désactivés sur les exécuteurs autohébergés. Vous pouvez activer ou désactiver cette fonctionnalité explicitement en définissant CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES sur true ou false dans l’environnement. Pour plus d’informations sur les variables d’environnement, consultez Stocker des informations dans des variables.

Pour les exécuteurs autohébergés, sauf si l’installation automatique des dépendances est activée, vous devrez probablement installer le compilateur gcc et certains projets peuvent également nécessiter un accès à clang ou msvc des exécutables. Vous devez également installer le système de build (par exemplemsbuild, make, cmake, bazel) et les utilitaires (tels que python, perl, lex et yacc) dont dépendent vos projets. Si vous activez l’installation automatique des dépendances, vous devez vous assurer que l’exécuteur utilise Ubuntu et qu’il peut exécuter sudo apt-get sans demander de mot de passe.

Les exécuteurs Windows exigent que powershell.exe soit sur PATH.

Génération de C#

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux
Système de build	.NET et MSbuild ainsi que les scripts de build

Indicateurs du compilateur C# injectés par CodeQL

Le traceur CodeQL permet l’extraction de tous les langages compilés en interceptant les processus de génération et en transférant des informations aux extracteurs de langage CodeQL appropriés. Le traceur injecte certains indicateurs dans l’appel du compilateur C# pour garantir que chaque composant est généré et inclus dans la base de données CodeQL. En conséquence, votre code C# peut être généré différemment de ce à quoi vous vous attendiez pendant l’analyse CodeQL.

/p:MvcBuildViews=true

Lorsque vous réglez cette option sur true, les vues dans les projets modèle-vue-contrôleur (MVC) ASP.NET sont précompilées dans le cadre du processus de génération, ce qui peut aider à détecter les erreurs et à améliorer les performances. Le traceur injecte cet indicateur pour garantir que CodeQL recherche et met en évidence les problèmes de sécurité susceptibles d’impliquer le flux de données via le code généré à partir de ces vues. Pour plus d’informations, consultez Ajouter un Affichage à une application MVC dans Microsoft Learn.

/p:UseSharedCompilation=false

En réglant cette option sur false, vous désactivez l’utilisation de la fonctionnalité de compilation partagée, ce qui peut entraîner des délais de génération plus lents. Quand /p:UseSharedCompilation=false n’est pas spécifié, msbuild démarre un processus serveur de compilateur et toute la compilation est effectuée par ce processus unique. Toutefois, le traceur CodeQL dépend de l’inspection des arguments des processus nouvellement créés.

/p:EmitCompilerGeneratedFiles=true

Régler cette option sur true émettra des fichiers générés par le compilateur pendant le processus de génération. Cette option permet au compilateur de générer des fichiers sources supplémentaires, utilisés pour prendre en charge des fonctionnalités telles que la prise en charge améliorée des expressions régulières, la sérialisation et la génération de vues d’applications web. Ces artefacts générés ne sont généralement pas écrits sur le disque par le compilateur, mais règlent l’option sur true pour forcer l’écriture des fichiers sur disque, pour que l’extracteur puisse traiter les fichiers.

Pour certains projets hérités et les projets qui utilisent des fichiers .sqlproj, vous pouvez voir que la propriété /p:EmitCompilerGeneratedFiles=true injectée provoque des problèmes inattendus avec msbuild. Pour obtenir des informations sur la résolution de ces erreurs, consultez Échec inattendu du compilateur C#.

Autodétection Windows

Le processus autobuild tente de détecter automatiquement une méthode de génération appropriée pour C# en utilisant l’approche suivante :

1. Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
2. Invoquer MSBuild.exe sur le fichier solution ou projet le plus proche de la racine. Si autobuild détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.
3. Invoquer un script qui ressemble à un script de génération : build.bat, build.cmd et build.exe (dans cet ordre).

Configuration requise pour C# sur Windows

Pour le développement d’applications .NET Core sur des exécuteurs auto-hébergés, vous aurez besoin du Kit de développement logiciel (SDK) .NET (pour dotnet).

Pour le développement d’applications .NET Framework, vous aurez besoin de Microsoft Build Tools (pour msbuild) et de l’interface CLI NuGet (pour nuget).

Les exécuteurs Windows exigent que powershell.exe soit sur PATH.

Autodétection Linux et macOS

1. Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
2. Invoquer MSbuild sur le fichier solution ou projet le plus proche de la racine. Si autobuild détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.
3. Invoquer un script qui ressemble à un script de génération : build et build.sh (dans cet ordre).

Configuration requise pour C# sur Linux et macOS

Pour le développement d’applications .NET Core sur des exécuteurs auto-hébergés, vous aurez besoin du Kit de développement logiciel (SDK) .NET (pour dotnet).

Pour le développement d’applications .NET Framework, vous aurez besoin de runtime Mono (pour exécuter mono, msbuild ou nuget).

Génération de Go

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux
Système de build	Modules Go, dep et Glide, ainsi que des scripts de génération, notamment des scripts Makefiles et Ninja

Autodetection pour Go

Le processus autobuild tente de détecter automatiquement un moyen approprié d’installer les dépendances dont un dépôt Go a besoin avant d’extraire tous les fichiers .go :

1. Appelez make, ninja, ./build ou ./build.sh (dans cet ordre) jusqu’à ce que l’une de ces commandes réussisse et qu’une commande go list ./... ultérieure réussisse également, indiquant que les dépendances nécessaires ont été installées.
2. Si aucune de ces commandes ne réussit, recherchez go.mod, Gopkg.toml ou glide.yaml, et exécutez go get (sauf si le vendoring est utilisé), dep ensure -v ou glide install respectivement pour essayer d’installer les dépendances.
3. Enfin, si les fichiers de configuration de ces gestionnaires de dépendances sont introuvables, réorganisez la structure de répertoires du dépôt pour l’ajouter à GOPATH et utilisez go get pour installer les dépendances. La structure de répertoires revient à la normale une fois l’extraction terminée.
4. Extrayez tout le code Go dans le dépôt, comme pour l’exécution de go build ./....

Options d’extracteur pour Go

Par défaut, le code de test (code dans les fichiers se terminant par _test.go) n’est pas analysé. Vous pouvez remplacer cette option par l’option --extractor-option extract_tests=true lorsque vous utilisez le CodeQL CLI ou en définissant la variable d’environnement CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_TESTS sur true.

En outre, les répertoires vendor sont exclus de l’analyse Go de CodeQL par défaut. Vous pouvez passer outre en passant l’option --extractor-option extract_vendor_dirs=true lorsque vous utilisez le CodeQL CLI ou en réglant la variable d’environnement CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_VENDOR_DIRS sur true.

Génération de Java et Kotlin

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux (sans restriction)
Système de build	Gradle, Maven et Ant

Autodetection pour Java

Le processus autobuild tente de déterminer le système de build pour les codebases Java en appliquant cette stratégie :

1. Rechercher un fichier de build dans le répertoire racine. Rechercher les fichiers de build Gradle, puis Maven, puis Ant.
2. Exécuter le premier fichier de build trouvé. Si les fichiers Gradle et Maven sont présents, le fichier Gradle est utilisé.
3. Sinon, rechercher les fichiers de build dans les sous-répertoires directs du répertoire racine. Si un seul sous-répertoire contient des fichiers de build, exécutez le premier fichier identifié dans ce sous-répertoire (en utilisant la même préférence que pour 1). Si plusieurs sous-répertoires contiennent des fichiers de build, signaler une erreur.

Configuration requise pour Java

Si vous utilisez des exécuteurs auto-hébergés, la ou les versions requises de Java doivent être présentes :

• Si l’exécuteur sera utilisé pour analyser les référentiels qui ont besoin d’une version unique de Java, la version JDK appropriée doit être installée et doit être présente dans la variable PATH (afin que java et javac soient trouvés).

• Si l’exécuteur sera utilisé pour analyser les référentiels qui ont besoin de plusieurs versions de Java, les versions JDK appropriées doivent être installées et peuvent être spécifiées via le fichier toolchains.xml. Ceci est un fichier de configuration, généralement utilisé par Apache Maven, qui vous permet de spécifier l’emplacement des outils, la version des outils et toute configuration supplémentaire requise pour utiliser les outils. Pour plus d’informations, consultez Guide d’utilisation des chaînes d’outils dans la documentation Apache Maven.

Les exécutables suivants seront probablement requis pour une gamme de projets Java et doivent être présents dans la variable PATH, mais ils ne seront pas essentiels dans tous les cas :

• mvn (Apache Maven)
• gradle (Gradle)
• ant (Apache Ant)

Vous devez également installer le système de build (par exemplemake, cmake, bazel) et les utilitaires (tels que python, perl, lex et yacc) dont dépendent vos projets.

Les exécuteurs Windows exigent que powershell.exe soit sur PATH.

Génération de Swift

Type de système pris en charge	Nom système
Système d’exploitation	macOS
Système de build	Xcode

Le processus autobuild tente de générer la plus grande cible à partir d’un projet ou d’un espace de travail Xcode.

L’analyse du code Swift utilise des exécuteurs macOS par défaut.

Code scanning du code Swift n’est pas pris en charge pour les exécuteurs qui font partie d’un ARC Actions Runner Controller, car les exécuteurs ARC utilisent uniquement Linux et Swift nécessite des exécuteurs macOS. Toutefois, vous pouvez avoir un mélange d’exécuteurs ARC et d’exécuteurs macOS auto-hébergés. Pour plus d’informations, consultez « À propos d’Actions Runner Controller ».

Personnalisation de la compilation Swift dans un Workflow d’analyse CodeQL

xcodebuild et swift build sont tous deux pris en charge pour les builds Swift. Nous vous recommandons de cibler une seule architecture pendant la génération. Par exemple, ARCH=arm64 pour xcodebuild, ou --arch arm64 pour swift build.

Vous pouvez passer les options archive et test à xcodebuild. Toutefois, la commande standard xcodebuild est recommandée, car elle doit être la plus rapide et doit être tout ce que CodeQL nécessite pour une analyse réussie.

Pour l’analyse Swift, vous devez toujours installer explicitement les dépendances gérées via CocoaPods ou Carthage avant de générer la base de données CodeQL.