À propos de la vérification des dépendances

À 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 demandes de tirage (pull request) qui contiennent des modifications apportées aux manifestes du package ou aux fichiers de verrouillage, vous pouvez afficher une révision 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.

Parfois, vous pouvez simplement mettre à jour la version d’une dépendance dans un manifeste et générer une demande de tirage. Toutefois, si la version mise à jour de cette dépendance directe a également des dépendances mises à jour, votre demande de tirage peut avoir 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 révisions de dépendances dans une demande de tirage et en changeant les dépendances marqué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 demande de tirage.

Les Dependabot alerts trouvent des vulnérabilités qui figurent déjà dans vos dépendances, mais il vaut bien mieux é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 À propos des alertes Dependabot.

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 pour le graphe des dépendances ».

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

À 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.

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 les référentiels privésavec GitHub Advanced Security 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 à travers 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 l’API API de soumission de dépendances. Pour plus d’informations sur l’API API de soumission de dépendances, consultez Utilisation de l’API de soumission de dépendances.

Vous pouvez configurer la action de révision des dépendances pour mieux répondre à 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 révision des dépendances ».

Meilleures pratiques pour l’utilisation conjointe des API de révision de dépendance et API de soumission de dépendances

L’API de révision de dépendance et le action de révision des dépendances fonctionnent tous deux en comparant les changements de dépendance dans une demande de tirage avec l’état de vos dépendances dans le head commit de votre branche cible.

Si votre référentiel ne dépend que de dépendance définies statiquement dans l'un des écosystèmes pris en charge par GitHub, l'API de révision de dépendance et action de révision des dépendances fonctionnent de manière cohérente.

Cependant, il se peut que vous souhaitiez que vos dépendances soient analysées lors d’une génération, puis chargées vers l’API API de soumission de dépendances. Dans ce cas, vous devez suivre certaines pratiques recommandées pour vous assurer que vous n’introduisez aucune condition de concurrence lors de l’exécution des processus pour l’API de révision de dépendance et l’API API de soumission de dépendances, car cela pourrait résulter sur des données manquantes.

Les meilleures pratiques à adopter dépendent de l’utilisation de GitHub Actions pour accéder à l’API API de soumission de dépendances et à l’API de révision de dépendance, ou de l’utilisation d’un accès direct à l’API.

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

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

• Veillez à exécuter toutes vos actions de soumission de dépendance dans le même flux de travail GitHub Actions 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 action de révision des dépendances séparément, suivez les instructions suivantes :
  • Affectez la valeur 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 d’un accès direct à l’API API de soumission de dépendances et à l’API de révision de dépendance

Si vous n’utilisez pas GitHub Actions et que votre code repose sur un accès direct à l’API API de soumission de dépendances et à l’API de révision de dépendance :

• Veillez à exécuter d’abord le code qui appelle l’API API de soumission de dépendances, puis le code qui appelle l’API de révision de dépendance.
• Si vous choisissez d’exécuter le code de l’API API de soumission de dépendances et de l’API de révision de dépendance en parallèle, vous devez mettre en œuvre une logique de nouvelle tentative et tenir compte de 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 des réessais exponentiels.
  • 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.

Pour aller plus loin

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