Skip to main content

Vérification des dépendances

La révision des dépendances vous permet d’intercepter les dépendances non sécurisées avant de les introduire dans votre environnement et fournit des informations sur la licence, les dépendants et l’âge des dépendances.

Qui peut utiliser cette fonctionnalité ?

La révision des dépendances est disponible pour les types de référentiels suivants :

  • Des référentiels publics sur GitHub.com
  • Référentiels appartenant à l’organisation sur GitHub Team avec GitHub Code Security activé

À propos de la vérification des dépendances

Une révision des dépendances vous aide à comprendre les changements de dépendances et l’impact de ceux-ci sur la sécurité à chaque demande de tirage. Cette fonctionnalité fournit une visualisation facilement compréhensible des changements de dépendances avec des différences enrichies sous l’onglet « Fichiers modifiés » d’une demande de tirage (pull request). Une révision des dépendances vous informe de ce qui suit :

  • Dépendances ajoutées, supprimées ou mises à jour, ainsi que leurs dates de publication
  • Nombre de projets utilisant ces composants
  • Données de vulnérabilité pour ces dépendances

Pour les pull requests qui contiennent des modifications apportées aux manifestes de paquet ou aux fichiers de verrouillage, vous pouvez afficher un examen des dépendances pour voir ce qui a changé. La révision des dépendances inclut des détails sur les modifications apportées aux dépendances indirectes dans les fichiers de verrouillage et vous indique si l’une des dépendances ajoutées ou mises à jour contient des vulnérabilités connues.

Remarque

Le « action de révision des dépendances » fait référence à l’action spécifique qui peut signaler les différences dans une pull request dans le contexte de GitHub Actions et ajouter des mécanismes d’application des règles au workflow GitHub Actions. Pour plus d’informations, consultez La action de révision des dépendances suite de cet article.

Parfois, vous pouvez simplement mettre à jour la version d’une dépendance dans un manifeste et générer une pull request. Toutefois, si la version mise à jour de cette dépendance directe a également des dépendances mises à jour, votre pull request peut contenir plus de modifications que prévu. La révision des dépendances pour chaque manifeste et fichier de verrouillage offre un moyen simple de voir ce qui a changé et de déterminer si l’une des nouvelles versions de dépendances contient des vulnérabilités connues.

En vérifiant les examens des dépendances dans une pull request et en changeant les dépendances signalées comme vulnérables, vous pouvez éviter l'ajout de vulnérabilités à votre projet. Pour plus d’informations sur le fonctionnement d’une révision de dépendances, consultez Révision des changements de dépendances dans une pull request.

Dependabot alerts trouvera des vulnérabilités qui se trouvent déjà dans vos dépendances, mais il est beaucoup mieux d’éviter d’introduire des problèmes potentiels que de résoudre les problèmes à une date ultérieure. Pour plus d’informations sur Dependabot alerts, consultez Dependabot alerts.

La révision des dépendances prend en charge les mêmes langages et les mêmes écosystèmes de gestion des packages que le graphe de dépendances. Pour plus d’informations, consultez « Écosystèmes de packages pris en charge par le graphe des dépendances ».

Pour plus d’informations sur les fonctionnalités de la chaîne d’approvisionnement disponibles sur GitHub, consultez Sécurité de la chaîne d’approvisionnement.

Activation de l'examen des dépendances

La fonctionnalité de révision des dépendances devient disponible quand vous activez le graphe de dépendances. Pour plus d’informations, consultez Activation du graphe des dépendances.

À propos de action de révision des dépendances

Le « action de révision des dépendances » fait référence à l’action spécifique qui peut signaler les différences dans une demande de tirage dans le contexte GitHub Actions. Consultez l’article dependency-review-action. Vous pouvez utiliser action de révision des dépendances pour appliquer des révisions de dépendances sur les demandes de tirage (pull requests) dans votre référentiel. L’action analyse les versions vulnérables des dépendances introduites par les modifications de version de package dans les demandes de tirage et vous avertit des vulnérabilités de sécurité associées. Cela vous donne une meilleure visibilité de ce qui change dans une demande de tirage et contribue à éviter l’ajout de vulnérabilités à votre dépôt.

Capture d’écran d’une exécution de workflow qui utilise l’action Révision des dépendances.

Par défaut, la action de révision des dépendances échoue si elle découvre des packages vulnérables. Une vérification ayant échoué empêche la fusion d’une demande de tirage lorsque le propriétaire du référentiel requiert la vérification de l’évaluation des dépendances. Pour plus d’informations, consultez « À propos des branches protégées ».

L’action est disponible pour tous les référentiels publics, ainsi que pour les référentiels privés pour lesquels GitHub Code Security or GitHub Advanced Security est activé.

Les propriétaires de l’organisation peuvent déployer la révision des dépendances à grande échelle en appliquant l’utilisation de action de révision des dépendances dans les dépôt de l’organisation. Cela implique l’utilisation d’ensembles de règles de dépôt pour lesquels vous allez définir action de révision des dépendances comme flux de travail requis, ce qui signifie que les demandes de tirage ne peuvent être fusionnées qu’une fois que le flux de travail passe toutes les vérifications requises. Pour plus d’informations, consultez « Application de la révision des dépendances dans une organisation ».

L’action utilise l’API REST de révision des dépendances pour obtenir la différence des modifications de dépendance entre le commit de base et le commit de tête. Vous pouvez utiliser l’API de révision de dépendance pour obtenir la différence des modifications de dépendance, y compris les données de vulnérabilité, entre deux commits sur un dépôt. Pour plus d’informations, consultez « Points de terminaison d’API REST pour la révision des dépendances ». L’action prend également en compte les dépendances soumises via le API de soumission de dépendances. Pour plus d’informations sur API de soumission de dépendances, consultez Utilisation de l’API de soumission de dépendances.

Remarque

L’API de révision de dépendance et l’API API de soumission de dépendances fonctionnent ensemble. Cela signifie que l’API de révision de dépendance inclut les dépendances soumises via l’API API de soumission de dépendances.

Vous pouvez configurer le action de révision des dépendances mieux adapté à vos besoins. Par exemple, vous pouvez spécifier le niveau de gravité qui fera échouer l’action, ou définir une liste d’autorisation ou de refus pour les licences à analyser. Pour plus d’informations, consultez « Configuration de l’action de revue des dépendances ».

Bonnes pratiques pour utiliser conjointement l’API de révision des dépendances et API de soumission de dépendances

L’API d’examen des dépendances et le action de révision des dépendances fonctionnent tous deux en comparant les modifications apportées aux dépendances dans une pull request avec l’état de vos dépendances dans le commit de tête de votre branche cible.

Si votre référentiel dépend uniquement des dépendances définies de manière statique dans l’un des GitHubécosystèmes pris en charge, l’API de révision des dépendances et le action de révision des dépendances travail de manière cohérente.

Toutefois, vous souhaiterez peut-être que vos dépendances soient analysées pendant une compilation, puis téléversées vers le API de soumission de dépendances. Dans ce cas, il existe certaines bonnes pratiques que vous devez suivre pour vous assurer que vous n’introduisez pas de condition de concurrence lors de l’exécution des processus de l’API de révision des dépendances et de l’API API de soumission de dépendances, car cela peut entraîner des données manquantes.

Les meilleures pratiques à adopter dépendront selon que vous utilisez GitHub Actions pour accéder à API de soumission de dépendances et à l’API d’examen des dépendances, ou que vous utilisez un accès direct à l’API.

Utilisation de GitHub Actions pour accéder au API de soumission de dépendances et à l’API de révision des dépendances

Si vous utilisez GitHub Actions pour accéder à API de soumission de dépendances ou à l’API de révision des dépendances :

  • Veillez à exécuter toutes vos actions de soumission des dépendances dans le même GitHub Actions flux de travail que votre action de révision des dépendances. Cela vous permettra de contrôler l'ordre d'exécution et de garantir que la révision de dépendance fonctionnera toujours.
  • Si vous choisissez d’exécuter le action de révision des dépendances fichier séparément, vous devez :
    • Définissez retry-on-snapshot-warnings à true.
    • Définissez retry-on-snapshot-warnings-timeout sur une valeur légèrement supérieure à la durée d’exécution typique (en secondes) de votre action de soumission de dépendance la plus longue.

Utilisation de l’accès direct à l’API API de soumission de dépendances et à l’API de révision des dépendances

Si vous n’utilisez GitHub Actionspas, et que votre code s’appuie sur un accès direct à l’API API de soumission de dépendances de révision des dépendances :

  • Veillez à exécuter le code qui appelle le API de soumission de dépendances premier, puis exécutez le code qui appelle l’API de révision des dépendances par la suite.
  • Si vous choisissez d’exécuter le code pour l’API API de soumission de dépendances de révision des dépendances en parallèle, vous devez implémenter une logique de nouvelle tentative et noter ce qui suit :
    • Lorsque des instantanés manquent pour l'un ou l'autre côté de une comparaison, vous verrez une explication dans l' x-github-dependency-graph-snapshot-warnings en-tête (sous la forme d'une chaîne encodée en base64). Par conséquent, si l'en-tête n'est pas vide, vous devriez envisager de réessayer.
    • Mettre en œuvre une logique de réessai avec un recul exponentiel entre les tentatives.
    • Mettez en œuvre un nombre raisonnable de tentatives pour tenir compte de la durée d'exécution typique de votre code de soumission de dépendance.

Lectures complémentaires