À propos de la configuration par défaut
La configuration code scanning par défaut est le moyen le plus rapide, le plus simple et le plus faible de maintenance d’activer code scanning pour votre référentiel. En fonction du code de votre référentiel, la configuration par défaut crée automatiquement une configuration personnalisée code scanning . Une fois la configuration par défaut activée, le code écrit dans les langages pris en charge par CodeQL dans votre référentiel sera analysé à l'aide de CodeQL:
- À chaque envoi (push) sur la branche par défaut du dépôt, ou sur toute branche protégée. Pour plus d’informations sur les branches protégées, consultez À propos des branches protégées.
- Lors de la création ou de la validation d’une demande de tirage basée sur la branche par défaut du dépôt, ou sur toute branche protégée, à l’exclusion des demandes de tirage provenant de duplications.
- Selon une planification hebdomadaire.
Langues prises en charge
Nous vous recommandons d’activer l’installation par défaut pour les référentiels éligibles s’il est possible que les référentiels incluent au moins un langage pris en charge par CodeQL dans le futur. Si vous activez l’installation par défaut sur un référentiel qui n’inclut aucun langage pris en charge par CodeQL, la configuration par défaut n’exécute pas d’analyses ni n’utilise de minutes GitHub Actions. Si les langages pris en charge par CodeQL sont ajoutés à la branche par défaut du référentiel, la configuration par défaut commencera automatiquement à analyser les langages pris en charge par CodeQL et à utiliser GitHub Actions minutes. Pour plus d’informations sur les langages pris en charge par CodeQL, consultez À propos de l’analyse du code avec CodeQL.
Si le code d’un référentiel change pour inclure des CodeQLlangues prises en charge, GitHub met automatiquement à jour la code scanning configuration pour inclure la nouvelle langue. En cas d’échec avec la nouvelle configuration code scanning, GitHub reprendra automatiquement la configuration précédente pour éviter que le dépôt ne perde la couverture code scanning.
Personnalisation de la configuration par défaut
Après avoir exécuté une analyse initiale de votre code avec la configuration par défaut, vous pouvez apporter des modifications à votre configuration pour mieux répondre à vos besoins.
Options de configuration
Pour les configurations existantes de l’installation par défaut, vous pouvez modifier :
- Les langues qui seront analysées par la configuration par défaut.
- La suite de requêtes s’exécute pendant l’analyse. Pour plus d’informations sur les suites de requêtes disponibles, consultez Suites de requêtes CodeQL.
- Modèles de menace (préversion publique) à utiliser pour l’analyse. Votre choix de modèle de risque détermine quelles sources de données souillées sont traitées comme un risque pour votre application. Pendant les préversion publique, les modèles de menace sont pris en charge uniquement pour l’analyse de Java/Kotlin et C#. Pour plus d’informations sur les modèles de menace, consultez Inclure les sources locales de données souillées dans la configuration par défaut.
Si votre codebase dépend d’une bibliothèque ou d’une infrastructure qui n’est pas reconnue par les bibliothèques standard incluses CodeQL, vous pouvez également étendre la couverture dans la CodeQL configuration par défaut à l’aide de CodeQL packs de modèles. Pour plus d'informations, consultez Extension de la couverture de CodeQL avec les packs de modèles CodeQL dans la configuration par défaut.
Des options de configuration supplémentaires partagées entre tous les code scanning types d’installation sont disponibles. Consultez « Propriétés du référentiel pour code scanning ».
Programmes d’exécution disponibles
Vous pouvez utiliser la configuration par défaut pour toutes les CodeQLlangues prises en charge sur les exécuteurs auto-hébergés ou GitHubles exécuteurs hébergés.
Vous pouvez affecter des exécuteurs auto-hébergés pour la configuration par défaut en donnant aux exécuteurs l’étiquette par défaut code-scanning , ou vous pouvez éventuellement leur attribuer des étiquettes personnalisées afin que les référentiels individuels puissent utiliser différents exécuteurs.
Sauf cas particulier, nous vous recommandons de n’attribuer aux exécuteurs que l’étiquette code-scanning par défaut. Toutefois, vous pouvez utiliser des étiquettes personnalisées pour :
- Attribuez des exécuteurs autonomes plus puissants aux dépôts critiques pour une analyse plus rapide code scanning.
- Exécutez vos code scanning analyses sur une plateforme particulière (par exemple, macOS).
- Contrôle granulaire de la charge de travail pour vos GitHubexécuteurs hébergés et exécuteurs auto-hébergés.
À propos de l’installation avancée
Si vous avez besoin d’un contrôle plus précis sur votre code scanning configuration, vous devez plutôt configurer une configuration avancée. La configuration avancée de code scanning est utile lorsque vous devez personnaliser votre code scanning. Vous pouvez configurer code scanning avec ou avec GitHub Actions un système d’intégration continue ou de déploiement continu (CI/CD) externe.
Si vous exécutez l’analyse du code en utilisant plusieurs configurations, il arrive qu’une alerte ait plusieurs origines d’analyse. Si une alerte a plusieurs origines d’analyse, vous pouvez afficher l’état de l’alerte pour chaque origine d’analyse sur la page de l’alerte. Pour plus d’informations, consultez « À propos des alertes d’analyse du code ».
Avec GitHub Actions
En créant et en modifiant un GitHub Actions fichier de flux de travail, vous pouvez définir comment générer des langages compilés, choisir les requêtes à exécuter, sélectionner les langues à analyser, utiliser une build de matrice, etc. Vous avez également accès à toutes les options permettant de contrôler les workflows, par exemple : modifier le calendrier d’analyse, définir les déclencheurs de workflow, spécifier les exécuteurs spécialisés à utiliser.
Votre administrateur de site peut également rendre disponibles aux utilisateurs des actions tierces pour code scanning, en configurant GitHub Connect. Pour plus d’informations, consultez « Configuration de l’analyse du code pour votre appliance ».
Avec un système CI/CD tiers
En alternative à l'exécution de code scanning dans GitHub à l'aide de GitHub Actions, vous pouvez analyser le code dans un système CI/CD externe, puis charger les résultats dans GitHub.
CodeQL CLI Il s'agit d'un outil autonome en ligne de commande que vous pouvez utiliser pour analyser le code. Vous pouvez ajouter le CodeQL CLI à votre système tiers, ou utiliser un autre outil d'analyse statique tiers qui peut produire des résultats au format d'échange de résultats d'analyse statique (SARIF) 2.1.0. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/codeql-cli/getting-started-with-the-codeql-cli/about-the-codeql-cli) » et « [AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning) ».
Les alertes pour code scanning lesquelles vous générez en externe sont affichées de la même façon que celles que code scanning vous générez dans GitHub.
Étapes suivantes
Vous pouvez activer la configuration par défaut d’un référentiel unique, de plusieurs référentiels ou de tous les référentiels d’une organisation en même temps.
- Pour un référentiel unique, consultez Définition de la configuration par défaut pour l’analyse du code.
- Pour l’activation en bloc, consultez Définition de la configuration par défaut pour l’analyse du code à grande échelle.
Pour configurer la configuration avancée à la place, consultez Configuration avancée de l’analyse du code.