Configurer l’analyse du code
Vous pouvez configurer la façon dont GitHub analyse le code de votre projet à la recherche de vulnérabilités et d’erreurs. Lorsque vous choisissez votre propre configuration, vous gagnez du temps et vous décidez de la meilleure fréquence d’analyse du code pour votre projet. Dans cette unité, vous allez apprendre les principes fondamentaux de la configuration de l’analyse du code. Vous apprendrez également à configurer la fréquence des analyses et à les planifier en fonction de vos besoins en matière de référentiel et de développement.
Comme nous l’avons vu dans les unités précédentes, vous pouvez exécuter l’analyse du code sur GitHub, à l’aide de GitHub Actions ou à partir de votre système d’intégration continue (CI). La sélection de l’option d’installation avancée sur GitHub génère un fichier de flux de travail personnalisable que vous pouvez ensuite valider directement dans votre référentiel. En règle générale, vous n’avez pas besoin de modifier ce flux de travail. Toutefois, si nécessaire, vous pouvez personnaliser certains paramètres.
Vous pouvez, par exemple, modifier le flux de travail d’analyse CodeQL de GitHub pour spécifier la fréquence des analyses, les langages ou les répertoires à analyser et le code CodeQL que l’analyse recherche dans votre code. Vous devrez peut-être également modifier le flux de travail d’analyse CodeQL si vous utilisez un ensemble spécifique de commandes pour compiler votre code. L’analyse CodeQL ne constitue qu’un seul type d’analyse du code que vous pouvez effectuer dans GitHub. La place de marché GitHub contient plusieurs autres flux de travail d’analyse du code.
Passage de la configuration par défaut à l’analyse avancée du code
Si vous disposez déjà d’une configuration de référentiel pour utiliser l’analyse de code en tirant parti de la méthode de configuration par défaut, vous pouvez effectuer un basculement dans les paramètres pour utiliser la configuration en mode avancé. Accédez à la section Analyse du code sous Paramètres > Advanced Security, puis sélectionnez l’icône à trois points (...). Dans la liste déroulante, sélectionnez Passer à la version avancée. Ensuite, suivez les instructions pour désactiver CodeQL et réactivez-le avec le fichier de workflow généré par l'installation avancée.
Modifier le flux de travail d’analyse du code
GitHub enregistre les fichiers de flux de travail dans le répertoire .github/workflows de votre dépôt. Vous pouvez trouver un flux de travail que vous avez ajouté en recherchant son nom de fichier. Par exemple, par défaut, le fichier de flux de travail pour l’analyse du code CodeQL est appelé codeql-analysis.yml.
Pour modifier un fichier de flux de travail, procédez comme suit :
- Pour ouvrir l’éditeur de flux de travail, sélectionnez l’icône Modifier dans le coin supérieur droit de la vue de fichier.
Apportez vos modifications.
Une fois que vous avez modifié le fichier, sélectionnez Valider les modifications et remplissez le formulaire Valider les modifications. Vous pouvez valider directement dans la branche active ou créer une branche et démarrer une demande de tirage (pull request).
Consultez les sections suivantes pour obtenir des options courantes de configuration de l’analyse du code.
Configurer la fréquence
Une modification courante du fichier de flux de travail consiste à ajuster la fréquence à laquelle l’analyse du code se produit. Vous pouvez configurer le flux de travail d’analyse CodeQL pour analyser le code selon une planification ou lorsque des événements spécifiques se produisent dans un référentiel. Vous pouvez également modifier le fichier de workflow pour analyser le code lorsqu’un push est effectué et chaque fois qu’une pull request est créée. L’ajustement de cette fréquence 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 découvertes par GitHub, les chercheurs en sécurité et la communauté. Même lorsque les développeurs ne maintiennent pas activement le référentiel.
Analyse sur envoi (push)
Par défaut, le flux de travail d’analyse CodeQL utilise l’événement on:push pour déclencher une analyse du code à chaque envoi (push) vers la branche par défaut du référentiel et toutes les branches protégées. Pour que l’analyse du code soit déclenchée sur une branche spécifiée, le flux de travail doit exister dans cette branche. Si vous effectuez une analyse push, les résultats s’affichent sous l’onglet Sécurité de votre référentiel.
En outre, lorsqu’une analyse on:push retourne un résultat qui peut être mappé à une demande de tirage (pull request) ouverte, ces alertes s’affichent automatiquement sur une demande de tirage au même emplacement 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.
Analyse sur PR (demande de tirage)
Le flux de travail d’analyse CodeQL par défaut utilise l’événement pull_request pour déclencher une analyse de code sur les demandes de tirage ciblées sur la branche par défaut. Si une demande de tirage provient d’une fourche privée, l’événement pull_request n’est déclenché que si vous avez sélectionné l’option « Exécuter des flux de travail à partir de demandes de tirage (pull request) de la fourche » dans les paramètres du référentiel. Si vous analysez les demandes de tirage, les résultats s’affichent sous forme d’alertes dans une vérification des demandes de tirage.
Si vous utilisez le déclencheur pull_request, configuré pour analyser la validation de fusion de la demande de tirage plutôt que la validation de l’en-tête, les résultats produits sont plus efficaces et précis que ceux de l’analyse de l’en-tête de la branche sur chaque envoi (push). Toutefois, si vous utilisez un système d’intégration continue et de livraison continue (CI/CD) qui ne peut pas être configuré pour se déclencher sur des demandes de tirage, vous pouvez toujours utiliser le déclencheur on:push pour que l’analyse du code mappe les résultats aux demandes de tirage ouvertes sur la branche et ajoute les alertes en tant qu’annotations à une demande de tirage.
Définir les gravités entraînant l’échec de la vérification des demandes de tirage (pull requests)
Par défaut, seules les alertes avec le niveau de gravité Error ou le niveau de gravité de la sécurité Critical ou High entraînent l’échec de la vérification de la demande de tirage.
Ces échecs ne bloquent pas l’exécution de l’analyse du code, mais ils peuvent bloquer la fusion en fonction des règles de référentiel. Vous pouvez afficher les détails des échecs de demande de tirage dans l’onglet Alertes d’analyse du code sous Sécurité.
Vous pouvez configurer les niveaux de gravité qui entraînent l’échec des vérifications de demande de tirage dans les paramètres du référentiel, ou via des ensembles de règles de référentiel à l’aide de la règle Exiger les résultats de l’analyse du code. Les deux mécanismes fonctionnent, mais les ensembles de règles sont la méthode de configuration moderne et préférée.
- Sur GitHub.com, accédez à la page principale du référentiel. Sous le nom de votre référentiel, sélectionnez Paramètres.
- Dans la barre latérale gauche, sélectionnez Advanced Security.
- Dans la section Analyse de code, sous Règles de protection, utilisez le menu déroulant pour sélectionner le niveau de gravité pour lequel vous souhaitez déclencher un échec de la vérification de la demande de tirage.
Triez et rejetez les alertes d’analyse du code de façon responsable
La résolution du code est la méthode recommandée pour résoudre une alerte d’analyse de code. Toutefois, certaines alertes peuvent ne pas nécessiter de modification de code. Par exemple, l’alerte peut être un faux positif, apparaître uniquement dans le code de test ou représenter un risque que l’équipe ait décidé de ne pas corriger.
Ignorez les alertes uniquement après avoir examiné les détails de l’alerte et confirmé la raison. Lorsque vous ignorez une alerte, GitHub enregistre la raison de licenciement, supprime l’alerte du nombre d’alertes actuel, la déplace vers la liste fermée et empêche le même code de générer la même alerte dans les analyses ultérieures. Le licenciement s’applique à toutes les branches.
Choisissez soigneusement la raison de licenciement, car elle fait partie de l’enregistrement de sécurité du référentiel. Vous pouvez également ajouter un commentaire de licenciement pour expliquer la décision. Ce commentaire est ajouté à la chronologie des alertes et peut prendre en charge les révisions futures d’audit, de création de rapports et de conformité.
Utilisez des commentaires pour capturer des détails tels que :
Pourquoi l’alerte n’a pas besoin d’une modification de code
Qui a examiné la décision
Indique si la décision est temporaire ou permanente
Tout contrôle de compensation ou tout travail de suivi
Pour une gouvernance plus forte, les organisations peuvent utiliser le renvoi d’alerte délégué pour contrôler qui est autorisé à ignorer les alertes d’analyse du code. Cela permet d’empêcher les développeurs de clôturer des conclusions de sécurité sans examen et instaure un processus de triage assorti d’une plus grande responsabilisation.
Éviter les analyses inutiles des demandes de tirage (pull requests)
Vous 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 configurer ce paramètre en spécifiant on:pull_request:paths-ignore ou on:pull_request:paths dans le flux de travail d’analyse du code. 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.
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
paths-ignore:
- '**/*.md'
- '**/*.txt'
Ajuster la planification de l’analyse
Si vous utilisez le workflow d’analyse CodeQL par défaut, le flux de travail analyse le code dans votre référentiel une fois par semaine à une date et heure générées de manière aléatoire, en plus des analyses déclenchées par des événements. Pour ajuster cette planification, modifiez la valeur cron dans le flux de travail.
L’exemple suivant montre un flux de travail d’analyse CodeQL pour un référentiel avec une branche par défaut appelée main et une branche protégée appelée protected :
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
schedule:
- cron: '20 14 * * 1'
Ce flux de travail analyse les éléments suivants :
Chaque envoi (push) vers la branche par défaut et la branche protégée
Chaque demande de tirage (pull request) sur la branche par défaut
La branche par défaut tous les lundis à 14:20 UTC
Utiliser les suggestions de correction automatique de Copilot
GitHub Copilot Autofix aide les développeurs à résoudre les alertes d’analyse de code en suggérant des modifications ciblées du code. La correction automatique utilise les informations de l’alerte, de la base de code et de la pull request pour générer un correctif potentiel. Vous n'avez pas besoin d'un abonnement GitHub Copilot distinct pour utiliser Copilot Autofix. Il est disponible pour les référentiels publics sur GitHub.com et pour les référentiels appartenant à l’organisation avec GitHub Sécurité du code activée.
Les suggestions d’autocorrection ne sont pas des corrections automatiques. Il s’agit de modifications proposées qui doivent être examinées, testées et approuvées comme toute autre modification de code.
Lors de l’examen d’une suggestion Autofix :
Lisez l’alerte et comprenez le problème de sécurité.
Passez en revue les modifications de code suggérées.
Vérifiez que le correctif résout l’alerte sans modifier le comportement prévu.
Exécutez les tests du projet et toutes les vérifications de sécurité requises.
Modifiez la suggestion si nécessaire.
Intégrez le correctif à la pull request.
Vérifiez que l’alerte d’analyse du code est résolue après l’exécution des vérifications.
Si une suggestion de correction automatique n’est pas appropriée, ignorez la suggestion plutôt que de l’appliquer. Si l’alerte elle-même n’a pas besoin d’être corrigée, ignorez l’alerte avec la raison correcte et un commentaire clair.