{"meta":{"title":"Personnalisation de la configuration de l’action de révision des dépendances","intro":"Découvrez comment ajouter une personnalisation de base à la configuration de votre action de révision des dépendances.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/tutorials","title":"Tutorials"},{"href":"/fr/code-security/tutorials/secure-your-dependencies","title":"Sécurisez vos dépendances"},{"href":"/fr/code-security/tutorials/secure-your-dependencies/customize-dependency-review-action","title":"Personnaliser l'action de revue des dépendances"}],"documentType":"article"},"body":"# Personnalisation de la configuration de l’action de révision des dépendances\n\nDécouvrez comment ajouter une personnalisation de base à la configuration de votre action de révision des dépendances.\n\n## Présentation\n\naction de révision des dépendances analyse vos pull requests afin d’y détecter les modifications de dépendances et signale une erreur si de nouvelles dépendances présentent des vulnérabilités connues. Une fois installé, si l'exécution du workflow est marquée comme obligatoire, toutes les demandes d'extraction introduisant des paquets vulnérables connus seront empêchées d'être fusionnées.\n\nCe guide vous explique comment ajouter trois personnalisations très courantes : l'échec des builds en fonction du niveau de gravité des vulnérabilités, de la licence des dépendances et de la portée.\n\n### Prerequisites\n\nCe guide part du principe que :\n\n* Le graphe des dépendances est activé pour le référentiel. Pour plus d’informations, consultez « [Activation du graphe de dépendances](/fr/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/enable-dependency-graph#enabling-the-dependency-graph-for-a-repository) ».\n* GitHub Actions est activé pour le référentiel. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository) ».\n\n## Étape 1 : Ajout de l’action de révision des dépendances\n\nDans cette étape, nous allons ajouter le flux de travail de révision des dépendances à votre référentiel.\n\n1. Sur GitHub, accédez à la page principale du référentiel.\n2. Sous le nom de votre référentiel, cliquez sur ** Actions**.\n\n ![Capture d’écran des onglets du référentiel « github/docs ». L’onglet « Actions » est mis en surbrillance avec un encadré orange.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n3. Sous « Bien démarrer avec GitHub Actions», recherchez la catégorie « Sécurité », puis cliquez sur **Afficher tout**.\n4. Recherchez « Révision des dépendances », puis cliquez sur **Configurer**. Vous pouvez également rechercher « Révision des dépendances » en utilisant la barre de recherche.\n5. Cela ouvrira le fichier de flux de travail de la vérification des dépendances GitHub Actions, `dependency-review.yml`. Cela doit contenir les éléments suivants :\n\n ```yaml copy\n name: 'Dependency review'\n on:\n pull_request:\n branches: [ \"main\" ]\n\n permissions:\n contents: read\n\n jobs:\n dependency-review:\n runs-on: ubuntu-latest\n steps:\n - name: 'Checkout repository'\n uses: actions/checkout@v6\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n ```\n\n## Étape 2 : Modification de la gravité\n\nVous pouvez empêcher la fusion de code contenant des dépendances vulnérables en définissant 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`.\n\n1. Ajouter l’option `fail-on-severity` à la fin du fichier `dependency-review.yml` :\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n ```\n\n## Étape 3 : Ajout de licences pour bloquer\n\nLes 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 le build si le pull request introduit une dépendance qui contient la licence LGPL-2.0 ou BSD-2-Clause.\n\n1. Ajouter l’option `deny-licenses` à la fin du fichier `dependency-review.yml` :\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n ```\n\n## Étape 4 : Ajout d’étendues\n\nEnfin, 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.\n\n1. Ajouter l’option `fail-on-scopes` à la fin du fichier `dependency-review.yml` :\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n fail-on-scopes: development\n ```\n\n## Étape 5 : Vérifier la configuration\n\nLe fichier `dependency-review.yml` doit maintenant se présenter comme ceci :\n\n```yaml copy\n\nname: 'Dependency Review'\non: [pull_request]\n\npermissions:\n contents: read\n\njobs:\n dependency-review:\n runs-on: ubuntu-latest\n steps:\n - name: 'Checkout Repository'\n uses: actions/checkout@v6\n - name: Dependency Review\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n fail-on-scopes: development\n```\n\nVous pouvez utiliser cette configuration comme modèle pour vos propres configurations personnalisées.\n\nPour plus d’informations sur toutes les options de personnalisation possibles, consultez le [README](https://github.com/actions/dependency-review-action/blob/main/README.md#configuration) dans la documentation relative à l'action de vérification des dépendances.\n\n## Bonnes pratiques\n\nLorsque vous personnalisez votre configuration de révision des dépendances, vous pouvez suivre certaines bonnes pratiques :\n\n* 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.\n\n* 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.\n\n* 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.\n\n## Lectures complémentaires\n\n* [Configuration de l’action de revue des dépendances](/fr/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-dependency-review-action)\n* [Application de la révision des dépendances dans une organisation](/fr/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review)"}