À propos des alertes d’analyse du code

À propos des alertes provenant de code scanning

Vous pouvez configurer code scanning pour vérifier le code dans un référentiel à l’aide de l’analyse par défaut CodeQL , d’une analyse tierce ou de plusieurs types d’analyse. Une fois l’analyse terminée, les alertes résultantes s’affichent côte à côte dans l’affichage de sécurité du dépôt. Les résultats des outils tiers ou des requêtes personnalisées peuvent ne pas inclure toutes les propriétés visibles pour les alertes identifiées par l'analyse par défaut de GitHubCodeQL. Pour plus d’informations, consultez « Définition de la configuration par défaut pour l’analyse du code » et « Configuration avancée de l’analyse du code ».

Par défaut, code scanning analyse votre code régulièrement sur la branche par défaut et pendant les pull requests. Pour obtenir davantage de renseignements sur la gestion des alertes au sein d’une demande de tirage, consultez Triage des alertes d’analyse du code dans les demandes de tirage (pull request).

Pour les alertes de l'analyse CodeQL, vous pouvez utiliser la vue d'ensemble de la sécurité pour voir comment CodeQL est en cours d'exécution dans les pull requests dans les dépôts de votre organisation et pour identifier les dépôts où vous devrez peut-être prendre des mesures. Pour plus d’informations, consultez « Indicateurs d’alerte de demande de tirage CodeQL ».

Vous pouvez auditer les actions effectuées en réponse aux alertes code scanning à l’aide des outils GitHub. Pour plus d’informations, consultez « Audit des alertes de sécurité ».

À propos des détails des alertes

Chaque alerte met en évidence un problème avec le code et le nom de l’outil qui l’a identifié. Vous pouvez voir la ligne de code qui a déclenché l’alerte ainsi que les propriétés de l’alerte, telles que la gravité de l’alerte, la gravité de sécurité et la nature du problème. Les alertes vous indiquent également quand le problème a été introduit pour la première fois. Pour les alertes identifiées par CodeQL l’analyse, vous verrez également des informations sur la façon de résoudre le problème.

L’état et les détails présentés sur la page de l’alerte reflètent uniquement l’état de l’alerte sur la branche par défaut du référentiel, même si l’alerte existe sur d’autres branches. Vous pouvez consulter l’état de l’alerte sur les branches autres que la branche par défaut dans la section Branches affectées sur le côté droit de la page de l’alerte. Si une alerte n’existe pas sur la branche par défaut, l’état de l’alerte est « dans la demande de tirage » ou « dans la branche », et il est grisé. La section Développement affiche les branches liées et les demandes de tirage qui permettront de corriger l’alerte.

Si vous configurez code scanning en utilisant CodeQL, vous pouvez également trouver des problèmes de flux de données dans votre code. L’analyse du flux de données détecte les problèmes de sécurité potentiels dans le code, tels que l’utilisation de données non sécurisée, le passage d’arguments dangereux à des fonctions et la fuite d’informations sensibles.

Lorsque code scanning vous signale des alertes de flux de données, GitHub vous montre comment les données passent par le code. Code scanning vous permet d’identifier les zones de votre code qui fuitent des informations sensibles et qui peuvent être le point d’entrée des attaques par des utilisateurs malveillants.

À propos des alertes issues de plusieurs configurations

Vous pouvez exécuter plusieurs configurations d’analyse du code sur un référentiel, en utilisant différents outils et en ciblant différents langages ou zones du code. Chaque configuration de code scanning génère un ensemble unique d’alertes. Par exemple, une alerte générée à l’aide de l’analyse CodeQL par défaut GitHub Actions provient d’une configuration différente de celle d’une alerte générée en externe et chargée via l’APIcode scanning.

Si vous utilisez plusieurs configurations pour analyser un fichier, les problèmes détectés par la même requête sont signalés sous la forme d’alertes par plusieurs configurations. Si une alerte existe dans plusieurs configurations, le nombre de configurations apparaît en regard du nom de la branche dans la section « Branches affectées » à droite de la page des alertes. Pour voir les configurations d’une alerte, dans la section « Branches affectées », cliquez sur une branche. Un modal « Analyse des configurations » s’affiche avec les noms de chaque configuration générant l’alerte pour cette branche. Sous chaque configuration, vous pouvez voir quand son alerte a été mise à jour pour la dernière fois.

Une alerte peut afficher différents états de différentes configurations. Pour mettre à jour les états des alertes, réexécutez chaque configuration obsolète. Vous pouvez également supprimer les configurations obsolètes d’une branche pour supprimer les alertes obsolètes. Pour en savoir plus sur la suppression des configurations et des alertes devenues obsolètes, consultezRésoudre les alertes d'analyse de code.

À propos des étiquettes pour les alertes introuvables dans le code de l’application

          GitHub affecte une étiquette de catégorie aux alertes introuvables dans le code de l’application. L’étiquette est liée à l’emplacement de l’alerte.

• Généré : code généré par le processus de génération

• Test : code de test

• Bibliothèque : bibliothèque ou code tiers

• Documentation : Documentation

          Code scanning classe les fichiers par chemin d’accès au fichier. Vous ne pouvez pas classer manuellement les fichiers sources.
  

Dans cet exemple, une alerte est marquée comme dans le code « Test » dans la code scanning liste des alertes.

Lorsque vous cliquez pour voir les détails de l’alerte, vous voyez que le chemin du fichier est marqué comme code « Test ».

À propos des niveaux de gravité des alertes et de sécurité

Le niveau de gravité d’une code scanning alerte indique le risque que le problème ajoute à votre codebase.

•         **Niveau de gravité.** Toutes les code scanning alertes ont un niveau de `Error`, `Warning`ou `Note`.
  

•         **Niveau de gravité de sécurité.** Chaque alerte de sécurité trouvée à l’aide CodeQL a également un niveau de gravité de sécurité de `Critical`, , `High`ou `Medium``Low`.
  

Lorsqu’une alerte a un niveau de gravité de sécurité, code scanning affiche et utilise ce niveau de préférence pour le severity. Les niveaux de gravité de sécurité suivent le Système de Notation CVSS (Common Vulnerability Scoring System) standard, qui est également utilisé pour les avis dans le GitHub Advisory Database. Pour davantage d’informations, consultez CVSS : Échelle qualitative d’évaluation de la gravité.

Calcul des niveaux de gravité de sécurité

Lorsqu’une requête de sécurité est ajoutée à la CodeQL suite de requêtes par défaut ou étendue, l’équipe CodeQL d’ingénierie calcule la gravité de la sécurité comme suit.

1. Identifier l’ensemble des CVE auxquelles sont associées une ou plusieurs balises CWE correspondant à la nouvelle requête de sécurité.
2. Calculer le 75e centile des scores CVSS pour ces CVE.
3. Attribuer ce score comme niveau de gravité de sécurité pour la requête.
4. Lors de l’affichage des alertes générées par la requête, convertir les scores numériques en Critical, High, Medium ou Low conformément aux définitions CVSS.

Pour plus d’informations, consultez CodeQL la couverture CWE sur le CodeQL site de documentation.

À propos des alertes dans les demandes de tirage

          Code scanning les alertes peuvent apparaître sur les pull requests en tant que résultats de vérification et les annotations. Cela se produit dans les référentiels où code scanning :

• Est configuré en tant que contrôle de demande de fusion (par défaut, cela est limité aux demandes de fusion visant la branche par défaut)
• Est configuré pour analyser chaque fois que le code est envoyé (les résultats sont associés aux demandes de pull ouvertes)

Une alerte s’affiche uniquement dans une demande de tirage si toutes les lignes de code identifiées par l’alerte existent dans le diff de la demande de tirage.

Selon les règles de protection des branches, la vérification des «Code scanning résultats » peut être une vérification requise qui empêche la fusion des pull requests jusqu’à ce qu’elle passe.