{"meta":{"title":"Options de configuration de flux de travail pour l’analyse du code","intro":"Modifiez votre fichier de flux de travail pour configurer la façon dont la configuration avancée analyse le code dans votre projet pour détecter les vulnérabilités et les erreurs.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/reference","title":"Reference"},{"href":"/fr/code-security/reference/code-scanning","title":"Analyse du code"},{"href":"/fr/code-security/reference/code-scanning/workflow-configuration-options","title":"Options de configuration de flux de travail"}],"documentType":"article"},"body":"# Options de configuration de flux de travail pour l’analyse du code\n\nModifiez votre fichier de flux de travail pour configurer la façon dont la configuration avancée analyse le code dans votre projet pour détecter les vulnérabilités et les erreurs.\n\n\n\n## Prerequisites\n\nVous devez utiliser la configuration avancée pour code scanning et être capable de modifier le fichier de flux de travail dans lequel votre configuration est définie.\n\nLes exemples fournis dans cet article concernent le Workflow d’analyse CodeQL fichier. Par défaut, ce fichier est défini à `.github/workflows/codeql-analysis.yml`.\n\n## Fréquence d’analyse\n\nVous pouvez configurer l’analyse du Workflow d’analyse CodeQL code selon une planification ou lorsque des événements spécifiques se produisent dans un référentiel.\n\nL’analyse du code quand un utilisateur pousse (push) une modification et chaque fois qu’une demande de tirage est créée empêche les développeurs d’introduire de nouvelles vulnérabilités et erreurs dans le code. L’analyse du code selon une planification vous informe des dernières vulnérabilités et erreurs que GitHub, les chercheurs en sécurité et la communauté découvrent, même lorsque les développeurs ne gèrent pas activement le référentiel.\n\n### Analyse sur poussée\n\nPar défaut, l’événement Workflow d’analyse CodeQL utilise l’événement `on:push` pour déclencher une analyse de code sur chaque push vers la branche par défaut du référentiel et toutes les branches protégées. Pour code scanning être déclenché sur une branche spécifiée, le flux de travail doit exister dans cette branche. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#on) ».\n\nSi vous effectuez une analyse push, les résultats s’affichent sous l’onglet ** Security and quality** de votre référentiel. Pour plus d’informations, consultez « [Évaluation des alertes d’analyse du code pour votre référentiel](/fr/code-security/code-scanning/managing-code-scanning-alerts/assessing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository) ».\n\nPar ailleurs, quand une analyse `on:push` retourne des résultats pouvant être mappés à une demande de tirage ouverte, ces alertes s’affichent automatiquement sur la demande de tirage au même endroit que les autres alertes de demande de tirage. Les alertes sont identifiées en comparant l’analyse existante de la tête de la branche à l’analyse de la branche cible. Pour plus d’informations sur code scanning les alertes dans les pull requests, consultez [Triage des alertes d’analyse du code dans les demandes de tirage (pull request)](/fr/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests).\n\n### Analyse des demandes de tirage\n\nLa valeur par défaut Workflow d’analyse CodeQL utilise l’événement `pull_request` pour déclencher une analyse de code sur les demandes d’extraction ciblées sur la branche par défaut.\nSi une demande de tirage provient d’une duplication privée, l’événement `pull_request` est déclenché uniquement si vous avez sélectionné l’option « Exécuter des flux de travail à partir de demandes de tirage de fork » dans les paramètres du référentiel. Pour plus d’informations, consultez [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).\n\nPour plus d’informations sur l’événement `pull_request`, consultez [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows#pull_request).\n\nSi vous analysez des demandes de tirage, les résultats s’affichent sous forme d’alertes dans une vérification des demandes de tirage. Pour plus d’informations, consultez « [Triage des alertes d’analyse du code dans les demandes de tirage (pull request)](/fr/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests) ».\n\nL’utilisation du déclencheur `pull_request`, configuré pour analyser le commit de fusion de la demande de tirage au lieu du commit de tête, produit des résultats plus efficaces et plus exacts que l’analyse de la tête de la branche pour chaque poussée. Toutefois, si vous utilisez un système CI/CD qui ne peut pas être configuré pour se déclencher sur les pull requests, vous pouvez toujours utiliser le `on:push` déclencheur, et code scanning mappe les résultats aux pull requests ouvertes sur la branche et ajoute les alertes en tant qu'annotations sur le pull request. Pour plus d’informations, consultez [Analyse sur poussée](#scanning-on-push).\n\n> \\[!NOTE]\n> Si votre référentiel est configuré avec une file d’attente de fusion, vous devez inclure l’événement `merge_group` comme déclencheur supplémentaire pour code scanning. Cela garantit que les demandes de tirage sont également analysées lorsqu’elles sont ajoutées à une file d’attente de fusion. Pour plus d’informations, consultez « [Gestion d’une file d’attente de fusion](/fr/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) ».\n\n### Prévention des analyses inutiles des demandes de tirage\n\nVous souhaiterez peut-être éviter qu’une analyse du code ne soit déclenchée sur des demandes de tirage spécifiques ciblées sur la branche par défaut, quels que soient les fichiers qui ont été modifiés. Vous pouvez le configurer en spécifiant `on:pull_request:paths-ignore` ou `on:pull_request:paths` dans le code scanning flux de travail. Par exemple, si les seules modifications apportées à une demande de tirage concernent des fichiers portant l’extension `.md` ou `.txt`, vous pouvez utiliser le tableau `paths-ignore` suivant.\n\n```yaml copy\non:\n push:\n branches: [main, protected]\n pull_request:\n branches: [main]\n paths-ignore:\n - '**/*.md'\n - '**/*.txt'\n```\n\n> \\[!NOTE]\n\n```\n `on:pull_request:paths-ignore` et `on:pull_request:paths` définissent les conditions qui déterminent si les actions du workflow s’exécutent sur une demande de tirage. Ils ne déterminent pas les fichiers qui sont analysés quand les actions _sont_ exécutées. Quand une demande de tirage contient des fichiers qui ne sont pas mis en correspondance par `on:pull_request:paths-ignore` ou `on:pull_request:paths`, le workflow exécute les actions et analyse tous les fichiers modifiés dans la demande de tirage, y compris ceux mis en correspondance par `on:pull_request:paths-ignore` ou `on:pull_request:paths`, sauf si les fichiers ont été exclus. Pour plus d’informations sur l’exclusion de fichiers de l’analyse, consultez [Spécification des répertoires à analyser](#specifying-directories-to-scan).\n```\n\nPour plus d’informations sur l’utilisation de `on:pull_request:paths-ignore` et `on:pull_request:paths` pour déterminer quand un workflow s’exécute pour une demande de tirage, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n\n### Analyse selon une planification\n\nSi vous utilisez la valeur par défaut Workflow d’analyse CodeQL, le flux de travail analyse le code dans votre référentiel une fois par semaine, en plus des analyses déclenchées par des événements. Pour ajuster ce calendrier, modifiez la valeur `cron` pour l’événement `on.schedule` dans le flux de travail. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#onschedule) ».\n\n> \\[!NOTE]\n> Cet événement déclenche l’exécution d’un flux de travail uniquement si le fichier de flux de travail existe sur la branche par défaut.\n\n### Exemple\n\nL’exemple suivant montre un Workflow d’analyse CodeQL référentiel particulier qui a une branche par défaut appelée `main` et une branche protégée appelée `protected`.\n\n```yaml copy\non:\n push:\n branches: [main, protected]\n pull_request:\n branches: [main]\n schedule:\n - cron: '20 14 * * 1'\n```\n\nCe flux de travail analyse les éléments suivants :\n\n* Chaque envoi (push) vers la branche par défaut et la branche protégée\n* Chaque demande de tirage (pull request) sur la branche par défaut\n* La branche par défaut tous les lundis à 14:20 UTC\n\n## Système d’exploitation\n\n> \\[!NOTE]\n>\n> * L’analyse du code Swift utilise des exécuteurs macOS par défaut.\n\n```\n GitHubLes exécuteurs macOS hébergés sont plus coûteux que les exécuteurs Linux et Windows. Vous devez donc envisager uniquement d’analyser l’étape de génération. Pour plus d’informations sur la configuration de l’analyse du code pour Swift, consultez [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#considerations-for-building-swift). Pour plus d’informations sur la tarification des GitHubexécuteurs hébergés, consultez [AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions).\n```\n\n> * 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 « [Actions Runner Controller](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller) ».\n\nSi votre code nécessite une compilation d’un système d’exploitation spécifique, vous pouvez configurer le système d’exploitation dans votre Workflow d’analyse CodeQL. Modifiez la valeur de `jobs.analyze.runs-on` pour spécifier le système d'exploitation de l'ordinateur qui exécute votre code scanning action.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n runs-on: [ubuntu-latest]\n```\n\nSi vous choisissez d’utiliser un exécuteur auto-hébergé pour l’analyse du code, vous pouvez spécifier un système d’exploitation à l’aide d’une étiquette appropriée comme deuxième élément d’un tableau à deux éléments, après `self-hosted`.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n runs-on: [self-hosted, ubuntu-latest]\n```\n\n```\n CodeQL\n code scanning prend en charge les dernières versions d’Ubuntu, Windows et macOS. Les valeurs classiques de ce paramètre sont donc : `ubuntu-latest`, `windows-latest` et `macos-latest`. Pour plus d’informations, consultez « [AUTOTITLE](/actions/using-jobs/choosing-the-runner-for-a-job) » et « [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners) ».\n\n Si vous utilisez un exécuteur auto-hébergé, vous devez vous assurer que Git se trouve dans la variable PATH. Pour plus d’informations, consultez « [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) » et « [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners) ».\n```\n\nPour obtenir les spécifications recommandées (RAM, cœurs d’UC et disque) pour l’exécution CodeQL d’une analyse sur des machines\nauto-hébergées, consultez [Ressources matérielles recommandées pour l’exécution de CodeQL](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/recommended-hardware-resources-for-running-codeql).\n\n##\n\n```\n CodeQL emplacement de la base de données\n```\n\nEn règle générale, vous n’avez pas besoin de vous soucier de l’emplacement Workflow d’analyse CodeQLCodeQL des bases de données, car les étapes ultérieures recherchent automatiquement les bases de données créées par les étapes précédentes. Toutefois, si vous écrivez une étape de flux de travail personnalisée qui nécessite que la CodeQL base de données se trouve dans un emplacement de disque spécifique, par exemple pour charger la base de données en tant qu’artefact de flux de travail, vous pouvez spécifier cet emplacement à l’aide du `db-location` paramètre sous l’action `init` .\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n db-location: '${{ github.runner_temp }}/my_location'\n```\n\nLe Workflow d’analyse CodeQL s'attendra à ce que le chemin fourni dans `db-location` soit accessible en écriture, et à ce qu'il n'existe pas ou soit un répertoire vide. Lors de l’utilisation de ce paramètre dans un travail en cours d’exécution sur un exécuteur auto-hébergé ou avec un conteneur Docker, il incombe à l’utilisateur de s’assurer que le répertoire choisi est effacé entre les exécutions ou que les bases de données sont supprimées une fois qu’elles ne sont plus nécessaires. Cela n’est pas nécessaire pour les travaux s’exécutant sur GitHubdes exécuteurs hébergés, qui obtiennent une nouvelle instance et un système de fichiers propre chaque fois qu’ils s’exécutent. Pour plus d’informations, consultez « [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners) ».\n\nSi ce paramètre n’est pas utilisé, il Workflow d’analyse CodeQL crée des bases de données dans un emplacement temporaire de son propre choix. Actuellement, la valeur par défaut est `${{ github.runner_temp }}/codeql_databases`.\n\n## Langues à analyser\n\n```\n CodeQL\n code scanning prend en charge le code écrit dans les langues suivantes :\n```\n\n\n\n* C/C++\n* C#\n* Go\n* Java/Kotlin\n* JavaScript/TypeScript\n* Python\n* Ruby\n* Rust\n* Workflows rapides \\* GitHub Actions\n\n> \\[!NOTE]\n>\n> * Utilisez `java-kotlin` pour analyser le code écrit en Java, Kotlin ou les deux.\n> * Utilisez `javascript-typescript` pour analyser le code écrit en JavaScript, TypeScript ou les deux.\n\nPour plus d’informations, consultez la documentation disponible sur le site web de CodeQL : [Langages et frameworks pris en charge](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/).\n\n```\n CodeQL utilise les identificateurs de langue suivants :\n```\n\n| Langage | Identificateur | Identificateurs alternatifs facultatifs (le cas échéant) |\n| ------------------------ | ----------------------- | -------------------------------------------------------- |\n| C/C++ | `c-cpp` | `c` ou `cpp` |\n| C# | `csharp` | |\n| | | |\n| Workflows GitHub Actions | `actions` | |\n| | | |\n| Go | `go` | |\n| Java/Kotlin | `java-kotlin` | `java` ou `kotlin` |\n| JavaScript/TypeScript | `javascript-typescript` | `javascript` ou `typescript` |\n| Python | `python` | |\n| Ruby | `ruby` | |\n| | | |\n| Rust | `rust` | |\n| | | |\n| Swift | `swift` | |\n\n> \\[!NOTE]\n> Si vous spécifiez l'un des identificateurs alternatifs, cela équivaut à l'utilisation de l'identificateur de langue standard. Par exemple, la spécification `javascript` au lieu de `javascript-typescript` n’exclut pas l’analyse du code TypeScript. Vous pouvez également utiliser un fichier de configuration personnalisé pour exclure des fichiers de l’analyse à l’aide du paramètre `paths-ignore`. Pour plus d’informations, consultez [Utilisation d’un fichier de configuration personnalisé](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#custom-configuration-files) et [Spécification des répertoires à analyser](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#specifying-directories-to-scan).\n\nCes identificateurs de langage peuvent être utilisés comme arguments pour l’entrée `languages` de l’action `init`. Nous recommandons de ne fournir qu’un seul langage comme argument :\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n languages: javascript-typescript\n```\n\nLe fichier par défaut Workflow d’analyse CodeQL créé après [la configuration avancée de l’installation pour l’analyse du code avec CodeQL](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-advanced-setup-for-code-scanning-with-codeql) définit une matrice contenant une propriété nommée `language` qui répertorie les langues de votre référentiel qui seront analysées. Cette matrice a été automatiquement préremplie avec les langages pris en charge détectés dans votre référentiel. L’utilisation de la `language` matrice permet CodeQL d’exécuter chaque analyse de langage en parallèle et de personnaliser l’analyse pour chaque langue. Dans une analyse individuelle, le nom du langage de la matrice est fourni à l’action `init` comme argument pour l’entrée `languages`. Nous recommandons que tous les flux de travail adoptent cette configuration. Pour plus d’informations sur les matrices, consultez [Exécution de variantes de tâches dans un workflow](/fr/actions/using-jobs/using-a-matrix-for-your-jobs).\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n languages: ${{ matrix.language }}\n```\n\nSi votre flux de travail utilise la `language` matrice, CodeQL il analyse uniquement les langues de la matrice. Pour changer les langages que vous souhaitez analyser, modifiez la configuration de la matrice. Vous pouvez supprimer un langage pour empêcher son analyse. Il existe plusieurs raisons pour lesquelles vous pouvez souhaiter empêcher l’analyse d’un langage. Par exemple, le projet peut avoir des dépendances dans un langage autre que celui du corps principal de votre code, et vous préférerez peut-être ne pas voir les alertes pour ces dépendances. Vous pouvez également ajouter une langue qui n’était pas présente dans le référentiel lors code scanning de la configuration. Par exemple, si le référentiel contenait initialement uniquement JavaScript lors code scanning de la configuration et que vous avez ajouté ultérieurement du code Python, vous devez ajouter `python` à la matrice.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n ...\n strategy:\n fail-fast: false\n matrix:\n include:\n - language: javascript-typescript\n build-mode: none\n - language: python\n build-mode: none\n```\n\nPour les langages compilés, la matrice peut également être utilisée pour configurer le mode de génération à utiliser pour l’analyse en modifiant la valeur de la propriété `build-mode`. Pour plus d’informations sur les modes de génération, consultez [Analyse CodeQL pour les langages compilés](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#about-build-mode-none-for-codeql).\n\nSi votre flux de travail ne fournit pas d’argument à l’entrée `languages` de l’action `init` , CodeQL il est configuré pour exécuter des analyses séquentiellement. Dans ce cas, CodeQL détecte et tente automatiquement d’analyser toutes les langues prises en charge dans le référentiel. Selon la taille du référentiel et le nombre de langues, cela peut prendre beaucoup de temps. Si l’analyse d’un langage échoue dans ce mode, l’analyse de tous les langages échoue. Par conséquent, nous ne recommandons pas cette configuration.\n\n> \\[!NOTE]\n> Lors de l’analyse séquentielle des langues, le mode de génération par défaut de chaque langage sera utilisé. Sinon, si vous fournissez une étape `autobuild` explicite, toutes les langues prenant en charge le mode `autobuild` l’utiliseront, tandis que les autres continueront d’utiliser leur mode par défaut. Si une configuration du mode de génération plus complexe que celle-ci est nécessaire, vous devrez configurer une matrice.\n\n## Gravité des alertes pour les échecs de vérification\n\nVous pouvez utiliser des ensembles de règles pour empêcher la fusion des demandes de tirage (pull request) lorsque l’une des conditions suivantes est remplie :\n\n* Un outil requis détecte une alerte code scanning dont la gravité est spécifiée dans l’ensemble de règles.\n* L’analyse d’un outil requis est toujours en cours.\n* Un outil requis n’est pas configuré pour le référentiel.\n\nPour plus d’informations, consultez « [Définir la protection contre la fusion d’analyse du code](/fr/code-security/code-scanning/managing-your-code-scanning-configuration/set-code-scanning-merge-protection) ». Pour plus d’informations générales sur les ensembles de règles, consultez [À propos des ensembles de règles](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).\n\n## Catégorie d’analyse\n\nUtilisez `category` pour distinguer plusieurs analyses pour le même outil et le même commit, mais effectuées dans différents langages ou différentes parties du code. La catégorie que vous spécifiez dans votre workflow est incluse dans le fichier de résultats SARIF.\n\nCe paramètre est particulièrement utile si vous utilisez des monodépôts et que vous avez plusieurs fichiers SARIF pour différents composants du monodépôt.\n\n```yaml copy\n - name: Perform CodeQL Analysis\n uses: github/codeql-action/analyze@v4\n with:\n # Optional. Specify a category to distinguish between multiple analyses\n # for the same tool and ref. If you don't use `category` in your workflow,\n # GitHub will generate a default category name for you\n category: \"my_category\"\n```\n\nSi vous ne spécifiez pas de `category` paramètre dans votre flux de travail, GitHub génère un nom de catégorie pour vous, en fonction du nom du fichier de flux de travail qui déclenche l’action, le nom de l’action et toutes les variables de matrice. Par exemple:\n\n* Le workflow `.github/workflows/codeql-analysis.yml` et l’action `analyze` produisent la catégorie `.github/workflows/codeql.yml:analyze`.\n* Le workflow `.github/workflows/codeql-analysis.yml`, l’action `analyze` et les variables de matrice `{language: javascript-typescript, os: linux}` produisent la catégorie `.github/workflows/codeql-analysis.yml:analyze/language:javascript-typescript/os:linux`.\n\nLa valeur `category` apparaît en tant que propriété `.automationDetails.id` dans SARIF v2.1.0. Pour plus d’informations, consultez « [Prise en charge de SARIF pour l’analyse du code](/fr/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#runautomationdetails-object) ».\n\nLa catégorie que vous spécifiez ne remplace pas les détails de l’objet `runAutomationDetails` dans le fichier SARIF, le cas échéant.\n\n##\n\n```\n CodeQL packs de modèles\n```\n\nSi votre codebase dépend d’une bibliothèque ou d’une infrastructure qui n’est pas reconnue par les requêtes standard dans CodeQL, vous pouvez étendre la CodeQL couverture dans votre code scanning flux de travail en spécifiant des packs de modèles publiés CodeQL . Pour plus d'informations sur la création de vos propres packs de modèles, consultez [Création et utilisation de packs CodeQL](/fr/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-and-working-with-codeql-packs#creating-a-model-pack).\n\n> \\[!NOTE]\n> Les packs de modèles CodeQL sont actuellement en préversion publique et peuvent faire l’objet de modifications. Les packs de modèles sont pris en charge pour l’analyse C/C++, C#, Java/Kotlin, Python, Ruby et Rust.\n>\n> L’éditeur de modèle CodeQL de l’extension CodeQL pour Visual Studio Code prend en charge les dépendances de modélisation pour C#, Java/Kotlin, Python et Ruby.\n\n### Utilisation de CodeQL paquets de modèles\n\nPour ajouter un ou plusieurs packs de modèles publiés CodeQL, spécifiez-les à l’intérieur de l’entrée `with: packs:` dans la section `uses: github/codeql-action/init@v4` du flux de travail. Dans `packs`, vous spécifiez un ou plusieurs packages à utiliser et, éventuellement, la version à télécharger. Si vous ne spécifiez pas de version, la version la plus récente est téléchargée. Si vous voulez utiliser des packages qui ne sont pas disponibles publiquement, vous avez besoin de définir la variable d’environnement `GITHUB_TOKEN` sur une secret qui a accès aux packages. Pour plus d’informations, consultez « [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/security-guides/automatic-token-authentication) » et « [Utilisation de secrets dans GitHub Actions](/fr/actions/security-guides/encrypted-secrets) ».\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n queries: security-extended\n packs: my-company/my-java-queries@~7.8.9,my-repo/my-java-model-pack\n```\n\nDans cet exemple, les requêtes par défaut sont exécutées pour Java, ainsi que les requêtes d’une version supérieure ou égale à `7.8.9` et inférieures à `7.9.0` du pack de requêtes `my-company/my-java-queries`. Les dépendances modélisées dans la dernière version du pack de modèles `my-repo/my-java-model-pack` seront disponibles à la fois pour les requêtes par défaut et pour celles en `my-company/my-java-queries`.\n\n## Requêtes non par défaut\n\nQuand vous utilisez CodeQL pour analyser du code, le moteur d’analyse de CodeQL génère une base de données à partir du code et exécute des requêtes sur celle-ci. L’analyse CodeQL utilise un ensemble de requêtes par défaut, mais vous pouvez spécifier d’autres requêtes à exécuter en plus des requêtes par défaut.\n\n> \\[!TIP]\n> Vous pouvez aussi spécifier les requêtes à exclure de l’analyse ou à inclure dans l’analyse. L’utilisation d’un fichier de configuration personnalisé est alors nécessaire. Pour plus d’informations, consultez [fichiers de configuration personnalisés](#custom-configuration-files) et [exclusion de requêtes spécifiques de l’analyse](#excluding-specific-queries-from-analysis) ci-dessous.\n\nVous pouvez exécuter des requêtes supplémentaires si elles font partie d’un pack CodeQL publié sur le GitHub Container registry ou d’un pack CodeQL stocké dans un dépôt. Pour plus d’informations, consultez « [À propos de l’analyse du code avec CodeQL](/fr/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql-queries) ».\n\nLes options disponibles pour spécifier les requêtes supplémentaires à exécuter sont les suivantes :\n\n* `packs` pour installer un ou plusieurs packs de requêtes CodeQL et exécuter les requêtes ou la suite de requêtes par défaut de ces packs.\n* `queries` pour spécifier un seul fichier *.ql*, un répertoire contenant plusieurs fichiers *.ql*, un fichier de définition de suite de requêtes *.qls* ou une combinaison de ces possibilités. Pour plus d’informations sur les définitions de suites de requêtes, consultez [Création de suites de requêtes CodeQL](https://codeql.github.com/docs/codeql-cli/creating-codeql-query-suites/).\n\nVous pouvez utiliser à la fois `packs` et `queries` dans le même workflow.\n\nNous vous déconseillons de référencer les suites de requêtes directement à partir du dépôt `github/codeql`, par exemple `github/codeql/cpp/ql/src@main`. Ces requêtes doivent être recompilées et peuvent ne pas être compatibles avec la version de CodeQL actuellement active sur GitHub Actions, ce qui peut entraîner des erreurs lors de l’analyse.\n\n### Utilisation des packs de requêtes\n\nPour ajouter un ou plusieurs CodeQL packs de requêtes, ajoutez une `with: packs:` entrée dans la `uses: github/codeql-action/init@v4` section du flux de travail. Dans `packs`, vous spécifiez un ou plusieurs packages à utiliser et, éventuellement, la version à télécharger. Si vous ne spécifiez pas de version, la version la plus récente est téléchargée. Si vous voulez utiliser des packages qui ne sont pas disponibles publiquement, vous avez besoin de définir la variable d’environnement `GITHUB_TOKEN` sur une secret qui a accès aux packages. Pour plus d’informations, consultez « [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/security-guides/automatic-token-authentication) » et « [Utilisation de secrets dans GitHub Actions](/fr/actions/security-guides/encrypted-secrets) ».\n\n> \\[!NOTE]\n> Pour les flux de travail qui génèrent des CodeQL bases de données pour plusieurs langues, vous devez plutôt spécifier les CodeQL packs de requêtes dans un fichier de configuration. Pour plus [d’informations, consultez Spécification des packs de CodeQL requêtes](#specifying-codeql-query-packs) ci-dessous.\n\nDans l’exemple ci-dessous, `scope` correspond au compte d’organisation ou personnel qui a publié le package. Lorsque le flux de travail s'exécute, les quatre CodeQL packs de requêtes sont téléchargés depuis GitHub et les requêtes par défaut ou la suite de requêtes pour chaque pack s'exécutent.\n\n* La dernière version de `pack1` est téléchargée et toutes les requêtes par défaut sont exécutées.\n* La version 1.2.3 de `pack2` est téléchargée et toutes les requêtes par défaut sont exécutées.\n* La dernière version de `pack3` qui est compatible avec la version 3.2.1 est téléchargée et toutes les requêtes sont exécutées.\n* La version 4.5.6 de `pack4` est téléchargée et seules les requêtes trouvées dans `path/to/queries` sont exécutées.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n # Comma-separated list of packs to download\n packs: scope/pack1,scope/pack2@1.2.3,scope/pack3@~3.2.1,scope/pack4@4.5.6:path/to/queries\n```\n\n> \\[!NOTE]\n> Si vous spécifiez une version particulière d’un pack de requêtes à utiliser, sachez que la version que vous spécifiez peut éventuellement devenir trop ancienne pour être utilisée efficacement par le moteur par défaut CodeQL utilisé par l’action CodeQL . Pour garantir des performances optimales, si vous avez besoin de spécifier des versions de pack de requêtes exactes, envisagez de vérifier régulièrement si la version épinglée du pack de requêtes a besoin d’être incrémentée.\n>\n> Pour plus d’informations sur la compatibilité des packs, consultez [Informations de référence sur les packs de requêtes CodeQL](/fr/code-security/reference/code-scanning/codeql/codeql-cli/codeql-query-packs#codeql-pack-compatibility).\n\n### Téléchargement CodeQL de packs à partir de GitHub Enterprise Server\n\nSi votre flux de travail utilise des packs publiés sur une GitHub Enterprise Server installation, vous devez indiquer à votre flux de travail où les trouver. Pour ce faire, utilisez l’entrée `registries` de l’action github/codeql-action/init\\@v4 . Cette entrée accepte une liste de propriétés `url`, `packages`et `token`, comme indiqué ci-dessous.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n registries: |\n # URL to the container registry, usually in this format\n - url: https://containers.GHEHOSTNAME1/v2/\n\n # List of package glob patterns to be found at this registry\n packages:\n - my-company/*\n - my-company2/*\n\n # Token, which should be stored as a secret\n token: ${{ secrets.GHEHOSTNAME1_TOKEN }}\n\n # URL to the default container registry\n - url: https://ghcr.io/v2/\n # Packages can also be a string\n packages: \"*/*\"\n token: ${{ secrets.GHCR_TOKEN }}\n\n \n```\n\nComme les modèles de package dans la liste des registres sont examinés dans l’ordre, vous devez généralement placer les modèles de package les plus spécifiques en premier. Les valeurs pour `token` doivent être générées par l'instance GitHub à partir de laquelle vous téléchargez, avec la permission `read:packages`.\n\nNotez le `|` après le nom de la propriété `registries`. Cela est important, car GitHub Actions les entrées ne peuvent accepter que des chaînes. L’utilisation de `|` convertit le texte suivant en chaîne, qui sera analysé ultérieurement par l’action github/codeql-action/init\\@v4.\n\n### Utilisation des requêtes dans des packs QL\n\nPour ajouter une ou plusieurs requêtes, ajoutez une entrée `with: queries:` dans la section `uses: github/codeql-action/init@v4` du workflow. Si les requêtes se trouvent dans un dépôt privé, utilisez le paramètre `external-repository-token` pour spécifier un jeton doté de l’accès nécessaire pour extraire le dépôt privé.\n\nVous pouvez également spécifier des suites de requêtes dans la valeur de `queries`. Les suites de requêtes sont des collections de requêtes, généralement regroupées par objectif ou langage.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n # Comma-separated list of queries / packs / suites to run.\n # This may include paths or a built in suite, for example:\n # security-extended or security-and-quality.\n queries: security-extended\n # Optional. Provide a token to access queries stored in private repositories.\n external-repository-token: ${{ secrets.ACCESS_TOKEN }}\n```\n\nLes suites de requêtes suivantes sont intégrées à CodeQL code scanning et sont disponibles pour utilisation.\n\n| Suite de requêtes | Description |\n| :--------------------- | :---------------------------------------------------------------------------------------- |\n| `security-extended` | Requêtes issues de la suite par défaut, plus requêtes de gravité et de précision moindres |\n| `security-and-quality` | Requêtes de `security-extended`, plus requêtes de maintenabilité et de fiabilité. |\n\nPour plus d’informations, consultez [Suites de requêtes CodeQL](/fr/code-security/code-scanning/managing-your-code-scanning-configuration/built-in-codeql-query-suites).\n\nChacune de ces suites de requêtes contient un sous-ensemble différent des requêtes incluses dans le pack de requêtes CodeQL intégré pour ce langage. Les suites de requêtes sont générées automatiquement à l’aide des métadonnées de chaque requête. Pour plus d’informations, consultez [Métadonnées pour les requêtes CodeQL](https://codeql.github.com/docs/writing-codeql-queries/metadata-for-codeql-queries/).\n\n\n\nLorsque vous spécifiez une suite de requêtes, le moteur d’analyse CodeQL exécute l’ensemble par défaut de requêtes, ainsi que toutes les requêtes supplémentaires définies dans la suite de requêtes supplémentaire.\n\n### Utilisation de fichiers de configuration personnalisés\n\nSi vous utilisez aussi un fichier de configuration pour des paramètres personnalisés, tous les packs ou requêtes supplémentaires spécifiés dans votre workflow sont utilisés à la place de ceux spécifiés dans le fichier de configuration. Si vous voulez exécuter l’ensemble combiné de packs ou requêtes supplémentaires, préfixez la valeur des `packs` ou `queries` dans le workflow avec le symbole `+`. Pour plus d’informations, consultez [les fichiers de configuration personnalisés](#custom-configuration-files).\n\nDans l’exemple suivant, le symbole `+` garantit que les packs et requêtes supplémentaires spécifiés sont utilisés ensemble avec tous ceux spécifiés dans le fichier de configuration référencé.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main\n packs: +scope/pack1,scope/pack2@1.2.3,scope/pack3@4.5.6:path/to/queries\n```\n\n\n\n## Fichiers de configuration personnalisés\n\nUn fichier de configuration personnalisé est une autre façon de spécifier des packs et des requêtes supplémentaires à exécuter. Vous pouvez également utiliser le fichier pour désactiver les requêtes par défaut, exclure ou inclure les requêtes spécifiques et spécifier les répertoires à analyser au cours de l’analyse.\n\nDans le fichier de workflow, utilisez le paramètre `config-file` de l’action `init` pour spécifier le chemin d’accès au fichier de configuration que vous souhaitez utiliser. Cet exemple charge le fichier de configuration *./.github/codeql/codeql-config.yml*.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n```\n\nLe fichier de configuration peut être situé dans le référentiel que vous analysez ou dans un référentiel externe. L’utilisation d’un référentiel externe vous permet de spécifier des options de configuration pour plusieurs référentiels à un même emplacement. Quand vous référencez un fichier de configuration situé dans un dépôt externe, vous pouvez utiliser la syntaxe *OWNER/REPOSITORY/FILENAME\\@BRANCH* . Par exemple : *octo-org/shared/codeql-config.yml\\@main*.\n\nSi le fichier de configuration se trouve dans un référentiel privé externe, utilisez le paramètre `external-repository-token` de l’action `init` pour spécifier un jeton qui a accès au référentiel privé.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n external-repository-token: ${{ secrets.ACCESS_TOKEN }}\n```\n\nLes paramètres dans le fichier de configuration sont écrits au format YAML.\n\n### Spécification de packs de requêtes CodeQL\n\nVous spécifiez des CodeQL packs de requêtes dans un tableau. Notez que le format est différent du format utilisé par le fichier de workflow.\n\n```yaml copy\npacks:\n # Use the latest version of 'pack1' published by 'scope'\n - scope/pack1\n # Use version 1.2.3 of 'pack2'\n - scope/pack2@1.2.3\n # Use the latest version of 'pack3' compatible with 3.2.1\n - scope/pack3@~3.2.1\n # Use pack4 and restrict it to queries found in the 'path/to/queries' directory\n - scope/pack4:path/to/queries\n # Use pack5 and restrict it to the query 'path/to/single/query.ql'\n - scope/pack5:path/to/single/query.ql\n # Use pack6 and restrict it to the query suite 'path/to/suite.qls'\n - scope/pack6:path/to/suite.qls\n```\n\nLe format complet pour spécifier un pack de requêtes est `scope/name[@version][:path]`.\n`version` et `path` sont facultatifs.\n`version` est la plage de versions de semver. Si le paramètre est absent, la dernière version est utilisée. Pour plus d’informations sur les plages semver, consultez la [Documentation de semver sur npm](https://docs.npmjs.com/cli/v6/using-npm/semver#ranges).\n\nSi vous disposez d’un flux de travail qui génère plusieurs CodeQL bases de données, vous pouvez spécifier les CodeQL packs de requêtes à exécuter dans un fichier de configuration personnalisé à l’aide d’une carte imbriquée de packs.\n\n```yaml copy\npacks:\n # Use these packs for JavaScript and TypeScript analysis\n javascript:\n - scope/js-pack1\n - scope/js-pack2\n # Use these packs for Java and Kotlin analysis\n java:\n - scope/java-pack1\n - scope/java-pack2@v1.0.0\n```\n\n### Extension de la couverture de CodeQL avec des modèles de menace\n\n> \\[!NOTE]\n> Les modèles de menace se trouvent actuellement en préversion publique et peuvent être amenés à changer. Pendant la préversion publique, les modèles de risque ne sont pris en charge que par l’analyse pour Java/Kotlin et C#.\n\nLe modèle de risque par défaut inclut les sources distantes de données non fiables. Vous pouvez étendre le CodeQL modèle de menace pour inclure des sources locales de données non approuvées (par exemple : arguments de ligne de commande, variables d’environnement, systèmes de fichiers et bases de données) en spécifiant `threat-models: local` dans un fichier de configuration personnalisé. Si vous étendez le modèle de risques, celui par défaut sera également utilisé.\n\n### Spécification de requêtes supplémentaires\n\nVous spécifiez des requêtes supplémentaires dans un tableau `queries`. Chaque élément du tableau contient un paramètre `uses` avec une valeur qui identifie un fichier de requête unique, un répertoire contenant des fichiers de requête ou un fichier de définition de suite de requêtes.\n\n```yaml copy\nqueries:\n - uses: ./my-basic-queries/example-query.ql\n - uses: ./my-advanced-queries\n - uses: ./query-suites/my-security-queries.qls\n```\n\nSi vous le souhaitez, vous pouvez attribuer un nom à chaque élément de tableau, comme indiqué dans les exemples de fichiers de configuration ci-dessous. Pour plus d’informations sur les requêtes supplémentaires, consultez [Requêtes non par défaut](#non-default-queries) ci-dessus.\n\n### Désactivation des requêtes par défaut\n\nSi vous souhaitez uniquement exécuter des requêtes personnalisées, vous pouvez désactiver les requêtes de sécurité par défaut à l’aide de `disable-default-queries: true`.\n\n### Exclusion de requêtes spécifiques de l’analyse\n\nVous pouvez ajouter les filtres `exclude` et `include` à votre fichier de configuration personnalisé afin de spécifier les requêtes que vous souhaitez exclure ou inclure dans l’analyse.\n\nCela est utile si vous souhaitez exclure, par exemple :\n\n* Des requêtes spécifiques des suites par défaut (`security`, `security-extended` et `security-and-quality`).\n* Des requêtes spécifiques dont les résultats ne vous intéressent pas.\n* Toutes les requêtes qui génèrent des avertissements et des recommandations.\n\nVous pouvez utiliser des filtres `exclude` similaires à ceux du fichier de configuration ci-dessous pour exclure les requêtes que vous souhaitez supprimer de l’analyse par défaut. Dans l’exemple de fichier de configuration ci-dessous, les deux requêtes `js/redundant-assignment` et `js/useless-assignment-to-local` sont exclues de l’analyse.\n\n```yaml copy\nquery-filters:\n - exclude:\n id: js/redundant-assignment\n - exclude:\n id: js/useless-assignment-to-local\n```\n\nPour rechercher l’ID d’une requête, vous pouvez cliquer sur l’alerte dans la liste des alertes sous l’onglet ** Security and quality** . La page des détails de l’alerte s’ouvre. Le champ `Rule ID` contient l’ID de requête. Pour plus d’informations sur la page des détails de l’alerte, consultez [À propos des alertes d’analyse du code](/fr/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts#about-alert-details).\n\n> \\[!TIP]\n>\n> * L’ordre des filtres est important. La première instruction de filtre qui apparaît après les instructions relatives aux requêtes et les packs de requêtes détermine si les requêtes sont incluses ou exclues par défaut.\n> * Les instructions suivantes sont exécutées dans l’ordre et les instructions qui apparaissent plus tard dans le fichier sont prioritaires sur les instructions précédentes.\n\nVous trouverez un autre exemple illustrant l’utilisation de ces filtres dans la section [Exemples de fichiers de configuration](#example-configuration-files).\n\nPour plus d’informations sur l’utilisation des filtres `exclude` et `include` dans votre fichier de configuration personnalisé, consultez [Création de suites de requêtes CodeQL](/fr/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-codeql-query-suites#filtering-the-queries-in-a-query-suite). Pour plus d’informations sur les métadonnées de requête sur lesquelles vous pouvez définir un filtre, consultez [Métadonnées des requêtes CodeQL](https://codeql.github.com/docs/writing-codeql-queries/metadata-for-codeql-queries/).\n\n### Spécification des répertoires à analyser\n\nLorsque les bases de code sont analysées sans générer le code, vous pouvez restreindre code scanning les fichiers dans des répertoires spécifiques en ajoutant un `paths` tableau au fichier de configuration. Vous pouvez également exclure les fichiers de répertoires spécifiques de l’analyse en ajoutant un tableau `paths-ignore`. Vous pouvez utiliser cette option lorsque vous exécutez les CodeQL actions sur un langage interprété (Python, Ruby et JavaScript/TypeScript) ou lorsque vous analysez un langage compilé sans générer le code (actuellement pris en charge pour C/C++, C#, Java et Rust).\n\n```yaml copy\npaths:\n - src\npaths-ignore:\n - src/node_modules\n - '**/*.test.js'\n```\n\n> \\[!NOTE]\n>\n> * Les mots clés `paths` et `paths-ignore`, utilisés dans le contexte de code scanning fichier de configuration, à ne pas être confondus avec ces mêmes mots-clés lorsqu'ils sont utilisés pour `on..paths` dans un flux de travail. Lorsqu’ils sont utilisés pour modifier `on.` dans un workflow, ils déterminent si les actions sont exécutées lorsqu’un utilisateur modifie le code dans les répertoires spécifiés. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) ».\n> * Les caractères de motif de filtre `?`, `+`, `[`, `]` et `!` ne sont pas pris en charge et seront pris en compte littéralement.\n> * ```\n> Les caractères `**` ne peuvent être qu’au début ou à la fin d’une ligne, ou placés entre barres obliques, et vous ne pouvez pas mélanger `**` et autres caractères. Par exemple, `foo/**`, `**/foo` et `foo/**/bar` sont des syntaxes autorisées, mais `**foo` ne l'est pas. Toutefois, vous pouvez utiliser des étoiles uniques avec d’autres caractères, comme indiqué dans l’exemple. Vous devez utiliser des guillemets pour tout ce qui contient un caractère `*`.\n> ```\n\nPour l’analyse où le code est généré, si vous souhaitez limiter code scanning des répertoires spécifiques dans votre projet, vous devez spécifier les étapes de génération appropriées dans le flux de travail. Les commandes que vous devez utiliser pour exclure un répertoire de la génération dépendent de votre système de génération. Pour plus d’informations, consultez « [Analyse CodeQL pour les langages compilés](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#adding-build-steps-for-a-compiled-language) ».\n\nVous pouvez analyser rapidement de petites parties d’un référentiel lorsque vous modifiez du code dans des répertoires spécifiques. Vous devez à la fois exclure des répertoires dans vos étapes de génération et utiliser les mots clés `paths-ignore` et `paths` pour [`on.`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) dans votre workflow.\n\n\n\n### Exemples de fichiers de configuration\n\nCe fichier config ajoute la suite de requêtes `security-and-quality` à la liste des requêtes exécutées par CodeQL au moment de l’analyse de votre code. Pour plus d’informations sur les suites de requêtes disponibles pour une utilisation, consultez [Requêtes non par défaut](#non-default-queries).\n\n```yaml\nname: \"My CodeQL config\"\n\nqueries:\n - uses: security-and-quality\n```\n\nLe fichier config suivant désactive les requêtes par défaut et spécifie un ensemble de requêtes personnalisées à exécuter à la place. Il configure également CodeQL pour analyser les fichiers du répertoire *src* (par rapport à la racine), à l’exception du répertoire *src/node\\_modules* et des fichiers dont le nom finit par *.test.js*. Les fichiers présents dans *src/node\\_modules* et les fichiers dont le nom finit par *.test.js* sont donc exclus de l’analyse.\n\n```yaml\nname: \"My CodeQL config\"\n\ndisable-default-queries: true\n\nqueries:\n - name: Use an in-repository CodeQL pack (run queries in the my-queries directory)\n uses: ./my-queries\n - name: Use an external JavaScript CodeQL pack (run queries from an external repo)\n uses: octo-org/javascript-codeql-pack@main\n - name: Use an external query (run a single query from an external CodeQL pack)\n uses: octo-org/python-codeql-pack/show_ifs.ql@main\n - name: Use a query suite file (run queries from a query suite in this repo)\n uses: ./codeql-packs/complex-python-codeql-pack/rootAndBar.qls\n\npaths:\n - src\npaths-ignore:\n - src/node_modules\n - '**/*.test.js'\n```\n\nLe fichier de configuration suivant exécute uniquement les requêtes qui génèrent des alertes dont le niveau de gravité est Erreur. La configuration sélectionne d’abord toutes les requêtes par défaut, toutes les requêtes dans `./my-queries` et la suite par défaut dans `codeql/java-queries`, puis elle exclut toutes les requêtes qui génèrent des avertissements ou des recommandations.\n\n```yaml\nqueries:\n - name: Use an in-repository CodeQL query pack (run queries in the my-queries directory)\n uses: ./my-queries\npacks:\n - codeql/java-queries\nquery-filters:\n- exclude:\n problem.severity:\n - warning\n - recommendation\n```\n\n## Détails de la configuration\n\nSi vous préférez spécifier des détails de configuration supplémentaires dans le fichier de flux de travail, vous pouvez utiliser l’entrée `config` de la commande `init` de l’action CodeQL. La valeur de cette entrée doit être une chaîne YAML qui suit le format de fichier de configuration documenté dans [les fichiers de configuration personnalisés](#custom-configuration-files) ci-dessus.\n\n### Exemple de configuration\n\nCette étape d’un GitHub Actions fichier de flux de travail utilise une `config` entrée pour désactiver les requêtes par défaut, ajouter la `security-extended` suite de requêtes et exclure les requêtes avec lesquelles elles sont marquées `cwe-020`.\n\n```yaml\n- uses: github/codeql-action/init@v4\n with:\n languages: ${{ matrix.language }}\n config: |\n disable-default-queries: true\n threat-models: local\n queries:\n - uses: security-extended\n query-filters:\n - exclude:\n tags: /cwe-020/\n```\n\nVous pouvez utiliser la même approche pour spécifier toutes les options de configuration valides dans le fichier de workflow.\n\n> \\[!TIP]\n> Vous pouvez partager une configuration entre plusieurs référentiels à l’aide de GitHub Actions variables. L’un des avantages de cette approche est que vous pouvez mettre à jour la configuration dans un emplacement unique sans modifier le fichier de workflow.\n>\n> Dans l’exemple suivant, `vars.CODEQL_CONF` est une GitHub Actions variable. Sa valeur peut être le contenu de n’importe quel fichier de configuration valide. Pour plus d’informations, consultez « [Stocker des informations dans des variables](/fr/actions/learn-github-actions/variables#defining-configuration-variables-for-multiple-workflows) ».\n>\n> ```yaml\n> - uses: github/codeql-action/init@v4\n> with:\n> languages: ${{ matrix.language }}\n> config: ${{ vars.CODEQL_CONF }}\n> ```\n\n## Langues compilées\n\nPour les langages compilés, vous pouvez décider de la façon dont l’action CodeQL crée une base de données à des fins d’analyse CodeQL . Pour obtenir des informations sur les options de build disponibles, consultez [Analyse CodeQL pour les langages compilés](/fr/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages).\n\n## Chargement de données\n\n```\n GitHub peut afficher des données d’analyse du code générées en externe par un outil tiers. Vous pouvez charger les données d’analyse du code avec l’action `upload-sarif`. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github) ».\n```"}