Personnalisation de la configuration de l’action de révision des dépendances

Introduction

action de révision des dépendances analyse vos demandes de tirage à la recherche de changements de dépendances et génère une erreur si les nouvelles dépendances présentent des vulnérabilités connues. Une fois installé, si l’exécution du flux de travail est marquée comme obligatoire, les demandes d’extraction introduisant des paquets vulnérables connus seront bloquées pour ne pas être fusionnées.

Ce guide vous montre comment ajouter trois personnalisations très courantes : l’échec des constructions en fonction du niveau de gravité de la vulnérabilité, de la licence de dépendance et de l’étendue.

Prérequis

Ce guide part du principe que :

• Le graphe des dépendances est activé pour le dépôt . Pour plus d’informations, voir « Configuration du graphe de dépendances ».
• GitHub Actions est activé pour le référentiel. Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».

Étape 1 : Ajout de l’action de révision des dépendances

Dans cette étape, nous allons ajouter le flux de travail de révision des dépendances à votre référentiel.

1. Sur GitHub, accédez à la page principale du référentiel.

2. Sous le nom de votre dépôt, cliquez sur Actions.

   

3. Sous « Démarrer GitHub Actions », trouvez la catégorie « Sécurité », puis cliquez sur Afficher tout.

4. Recherchez « Révision des dépendances », puis cliquez sur Configurer. Vous pouvez également rechercher « Révision des dépendances » à l’aide de la barre de recherche.

5. Cela ouvrira le fichier de flux de travail GitHub Actions de la révision des dépendances, dependency-review.yml. Cela doit contenir les éléments suivants :

   YAML

   name: 'Dependency review'
   on:
     pull_request:
       branches: [ "main" ]
   
   permissions:
     contents: read
   
   jobs:
     dependency-review:
       runs-on: ubuntu-latest
       steps:
         - name: 'Checkout repository'
           uses: actions/checkout@v4
         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
   

Étape 2 : Modification de la gravité

Vous pouvez empêcher le code contenant des dépendances vulnérables d’être fusionné en définissant la action de révision des dépendances comme obligatoire. Toutefois, il convient de noter que le blocage des vulnérabilités à faible risque peut s’avérer trop restrictif dans certaines circonstances. Dans cette étape, nous allons modifier la gravité de la vulnérabilité qui entraînera l’échec de la construction avec l’option fail-on-severity.

1. Ajouter l’option fail-on-severity à la fin du fichier dependency-review.yml :

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
   

Étape 3 : Ajout de licences pour bloquer

Les vulnérabilités ne sont pas la seule raison pour laquelle vous pouvez vouloir bloquer une dépendance. Si votre organisation impose des restrictions sur les types de licences que vous pouvez utiliser, vous pouvez utiliser la révision des dépendances pour appliquer ces politiques avec l’option deny-licenses. Dans cette étape, nous allons ajouter une personnalisation qui interrompra la construction si la demande de retrait introduit une dépendance qui contient la licence LGPL-2.0 ou BSD-2-Clause.

1. Ajouter l’option deny-licenses à la fin du fichier dependency-review.yml :

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
             deny-licenses: LGPL-2.0, BSD-2-Clause
   

Étape 4 : Ajout d’étendues

Enfin, nous utiliserons l’option fail-on-scopes pour empêcher la fusion des dépendances vulnérables dans des environnements de déploiement spécifiques, dans ce cas l’environnement de développement.

1. Ajouter l’option fail-on-scopes à la fin du fichier dependency-review.yml :

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
             deny-licenses: LGPL-2.0, BSD-2-Clause
             fail-on-scopes: development
   

Étape 5 : Vérifier la configuration

Le fichier dependency-review.yml doit maintenant se présenter comme ceci :

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

Vous pouvez utiliser cette configuration comme modèle pour vos propres configurations personnalisées.

Pour plus d’informations sur toutes les options de personnalisation possibles, consultez le LISEZMOI dans la documentation de l’action de revue des dépendances.

Bonnes pratiques

Lorsque vous personnalisez votre configuration de révision des dépendances, vous pouvez suivre certaines bonnes pratiques :

• Préférez les listes de blocage aux listes d’autorisation. Il est plus pratique de compiler une liste des dépendances « très mauvaises » que l’on souhaite bloquer que de créer une liste exhaustive de toutes les bibliothèques que l’on souhaite autoriser.

• Choisissez de bloquer les licences au lieu de spécifier les licences à autoriser. Il existe une grande variété de licences, de sorte qu’il est généralement plus pratique d’exclure celles que vous savez incompatibles avec les licences actuelles que de compiler une liste complète des licences compatibles.

• Choisissez fail-on-severity. L’échec en fonction de la gravité d’une vulnérabilité est un bon moyen d’équilibrer le besoin de sécurité et la nécessité de créer des expériences à faible friction pour les développeurs.

Pour aller plus loin

• « Configuration de la révision des dépendances »