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 . Le graphe des dépendances est activé par défaut pour les dépôts publics et vous pouvez choisir de l’activer pour les dépôts privés . 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.
-
Sur GitHub, accédez à la page principale du référentiel.
-
Sous le nom de votre dépôt, cliquez sur Actions.
-
Sous « Démarrer GitHub Actions », trouvez la catégorie « Sécurité », puis cliquez sur Afficher tout.
-
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.
-
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
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
.
-
Ajouter l’option
fail-on-severity
à la fin du fichierdependency-review.yml
:YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate
- 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.
-
Ajouter l’option
deny-licenses
à la fin du fichierdependency-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
- 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.
-
Ajouter l’option
fail-on-scopes
à la fin du fichierdependency-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
- 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.