Utilisation de règles d’alerte pour hiérarchiser les priorités des alertes Dependabot

À propos des règles d’alerte Dependabot

Avec les règles d’alerte Dependabot, vous pouvez indiquer à Dependabot de masquer ou de rouvrir automatiquement certaines alertes, sur la base d’une logique complexe établie à partir de divers critères contextuels.

Lorsqu’elle est activée, la règle intégrée Dismiss low impact alerts masque automatiquement certains types de vulnérabilités qui sont trouvées dans les dépendances npm utilisées dans le développement. Ces alertes couvrent les cas qui sont considérés comme de fausses alarmes par la plupart des développeurs du fait que les vulnérabilités associées :

• Sont peu susceptibles d’être exploitables dans un environnement de développement (hors production ou de runtime).
• Peuvent être liées à des problèmes de gestion des ressources, de programmation et de logique, et de divulgation d’informations.
• Au pire, ont des effets limités comme des builds lentes ou des tests longs.
• Ne sont pas révélatrices de problèmes en production.

Cette règle Dismiss low impact alerts organisée par GitHub inclut les vulnérabilités liées à la gestion des ressources, à la programmation et à la logique, ainsi qu’à la divulgation d’informations. Pour plus d’informations, consultez « Listes de vulnérabilités publiquement connues (CWE) utilisées par la règle Masquer les alertes à faible impact ».

Le filtrage de ces alertes à faible impact vous permet de vous concentrer sur les alertes qui vous intéressent, sans risquer de manquer des alertes de développement potentiellement à haut risque.

Si vous choisissez de masquer automatiquement les alertes à faible impact, sachez que vous pouvez toujours rouvrir des alertes masquées automatiquement et aussi filtrer les alertes pour afficher celles qui ont été masquées automatiquement. Pour plus d’informations, consultez « Gestion des alertes masquées automatiquement ».

Par ailleurs, les alertes masquées automatiquement restent toujours disponibles pour la création de rapports et la révision, et elles peuvent même être réintégrées comme si elles n’avaient jamais été masquées, en cas de modification des métadonnées d’alerte, par exemple :

• Si vous modifiez l’étendue d’une dépendance de développement à production.
• Si GitHub modifie certaines métadonnées pour l’avis associé.

Les alertes masquées automatiquement sont définies par le motif de fermeture resolution:auto-dismiss. L’activité de masquage automatique est incluse dans les webhooks d’alerte, dans les API REST et GraphQL, ainsi que dans le journal d’audit. Pour plus d’informations, consultez « Dependabot alerts » dans la documentation de l’API REST, et la section « repository_vulnerability_alert » dans « Examen du journal d’audit de votre organisation ».

Par défaut, les règles d’alerte Dependabot organisées par GitHub sont activées sur les dépôts publics, mais désactivées sur les dépôts privés. Les administrateurs de dépôts privés peuvent choisir d’activer les règles d’alerte pour leur dépôt. Pour plus d’informations, consultez « Activation des règles d’alerte Dependabot pour votre dépôt privé ».

Activation des règles d’alerte Dependabot pour votre dépôt privé

Vous devez d’abord activer les Dependabot alerts pour le dépôt. Pour plus d’informations, consultez « Configuration d’alertes Dependabot ». Les

1. Dans GitHub.com, accédez à la page principale du dépôt.
2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
3. Dans la section « Sécurité » de la barre latérale, cliquez sur Sécurité et analyse du code.
4. Sous « Dependabot alerts », cliquez sur Masquer les alertes à faible impact.

Gestion des alertes masquées automatiquement

Vous pouvez filtrer les alertes pour afficher les alertes qui ont été masquées automatiquement, et vous pouvez aussi rouvrir des alertes masquées.

1. Dans GitHub.com, accédez à la page principale du dépôt.

2. Sous le nom du dépôt, cliquez sur Sécurité. Si vous ne voyez pas l’onglet « Sécurité », sélectionnez le menu déroulant et cliquez sur Sécurité.

3. Pour filtrer les alertes afin d’afficher toutes les alertes fermées, cliquez sur Fermées. Vous pouvez également utiliser la requête de filtre is:closed dans la barre de recherche.

   

4. Pour afficher toutes les alertes masquées automatiquement, sélectionnez Fermées en tant que, puis dans le menu déroulant, cliquez sur Masquées automatiquement.

   

5. Pour rouvrir une alerte masquée automatiquement, à gauche du titre de l’alerte, cliquez sur la case à cocher adjacente à l’alerte, puis cliquez sur Rouvrir.

   

Listes de vulnérabilités publiquement connues (CWE) utilisées par la règle Masquer les alertes à faible impact

En plus des métadonnées d’alerte ecosystem:npm et scope:development, nous utilisons les listes de vulnérabilités publiquement connues (CWE) suivantes, organisées par GitHub, pour filtrer les alertes à faible impact selon la règle Dismiss low impact alerts. Nous enrichissons régulièrement cette liste et les modèles de vulnérabilités couverts par les règles intégrées.

Problèmes de gestion des ressources

• CWE-400 Uncontrolled Resource Consumption (Consommation non contrôlée des ressources)
• CWE-770 Allocation of Resources Without Limits or Throttling (Allocation de ressources sans limite ni limitation)
• CWE-409 Improper Handling of Highly Compressed Data (Data Amplification) [Traitement incorrect des données hautement compressées (Amplification des données)]
• CWE-908 Use of Uninitialized Resource (Utilisation de ressource non initialisée)
• CWE-1333 Inefficient Regular Expression Complexity (Complexité d’expression régulière inefficace)
• CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop') [Boucle avec condition de sortie inaccessible (« Boucle infinie »)]
• CWE-674 Uncontrolled Recursion (Récursion non contrôlée)
• CWE-1119 Excessive Use of Unconditional Branching (Utilisation excessive de branches sans condition)

Erreurs de logique et de programmation

• CWE-185 Incorrect Regular Expression (Expression régulière incorrecte)
• CWE-754 Improper Check for Unusual or Exceptional Conditions (Vérification incorrecte de conditions inhabituelles ou exceptionnelles)
• CWE-755 Improper Handling of Exceptional Conditions (Traitement incorrect de conditions exceptionnelles)
• CWE-248 Uncaught Exception (Exception non interceptée)
• CWE-252 Unchecked Return Value (Valeur retournée non vérifiée)
• CWE-391 Unchecked Error Condition (Condition d’erreur non vérifiée)
• CWE-696 Incorrect Behavior Order (Ordre de comportement incorrect)
• CWE-1254 Incorrect Comparison Logic Granularity (Granularité de logique de comparaison incorrecte)
• CWE-665 Improper Initialization (Initialisation incorrecte)
• CWE-703 Improper Check or Handling of Exceptional Conditions (Vérification ou traitement incorrects de conditions exceptionnelles)
• CWE-178 Improper Handling of Case Sensitivity (Traitement incorrect du respect de la casse)

Problèmes de divulgation d’informations

• CWE-544 Missing Standardized Error Handling Mechanism (Absence de mécanisme standardisé de traitement des erreurs)
• CWE-377 Insecure Temporary File (Fichier temporaire non sécurisé)
• CWE-451 User Interface (UI) Misrepresentation of Critical Information (Présentation erronée d’informations critiques dans l’interface utilisateur)
• CWE-668 Exposure of Resource to Wrong Sphere (Exposition de ressource à une sphère incorrecte)