Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2026-04-09. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Détection des dépendances vulnérables

Si les informations de dépendance signalées par GitHub ce n’est pas ce que vous attendiez, il existe plusieurs points à prendre en compte et différentes choses que vous pouvez vérifier.

Dans cet article

Les résultats de la détection des dépendances signalés par GitHub peuvent être différents des résultats renvoyés par d’autres outils. Il existe de bonnes raisons à cela et il est utile de comprendre comment GitHub détermine les dépendances pour votre projet.

Dépendances manquantes ou non détectées

          GitHub génère et affiche les données de dépendance différemment des autres outils. Ainsi, si vous utilisez un autre outil pour identifier les dépendances, vous verrez très probablement des résultats différents. Tenez compte des éléments suivants :

  • GitHub Advisory Database est l’une des sources de données qui GitHub utilise pour identifier les dépendances vulnérables et les programmes malveillants. Il s’agit d’une base de données gratuite et organisée d’avis de sécurité pour les écosystèmes de packages communs sur GitHub. Il inclut les données rapportées directement de GitHub à GitHub Security Advisories, ainsi que les flux officiels et les sources communautaires. Ces données sont examinées GitHub et organisées en vue de s’assurer que les informations fausses ou inactionnables ne sont pas partagées avec la communauté de développement. Pour plus d’informations, consultez « Exploration des avis de sécurité dans la base de données GitHub Advisory ».

  • Le graphe de dépendances analyse tous les fichiers manifeste de package connus dans le dépôt d’un utilisateur. Par exemple, pour npm, il analyse le fichier package-lock.json. Il construit un graphe de la totalité des dépendances et des éléments dépendants publics du dépôt. Cela se produit quand vous activez le graphe de dépendances et que quelqu’un effectue vers la branche par défaut une poussée (push) comportant des commits qui changent un format de manifeste pris en charge. Pour plus d’informations, consultez « À propos du graphe de dépendances » et « Résolution des problèmes liés au graphe de dépendances ».

  • Dependabot analyse n’importe quel push, vers la branche par défaut, qui contient un fichier manifeste. Lorsqu’un nouvel avis est ajouté, il analyse tous les référentiels existants et génère une alerte pour chaque référentiel concerné. Dependabot alerts sont agrégés au niveau du référentiel, plutôt que de générer une alerte distincte pour chaque avis. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

  • Dependabot security updates sont déclenchés lorsque vous recevez une alerte concernant une dépendance vulnérable dans votre référentiel. Dans la mesure du possible, Dependabot crée une pull request dans votre référentiel pour mettre à niveau la dépendance vulnérable vers la version sécurisée minimale nécessaire pour éviter la vulnérabilité. Pour plus d’informations, consultez « À propos des mises à jour de sécurité Dependabot » et « Erreurs de Dependabot ».

            Dependabot n’analyse pas les référentiels selon une planification, mais plutôt quand quelque chose change. Par exemple, une analyse est déclenchée lorsqu’une nouvelle dépendance est ajoutée (GitHub vérifie cela sur chaque envoi push) ou lorsqu’un nouvel avis est ajouté à la base de données et synchronisé avec GitHub. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts#detection-of-insecure-dependencies) ».

Étendue de la couverture des alertes

          Dependabot alerts vous conseiller sur les dépendances que vous devez mettre à jour, y compris les dépendances transitives, où la version peut être déterminée à partir d’un manifeste ou d’un fichier de verrouillage. 
          Dependabot security updates suggèrent uniquement une modification où Dependabot peut directement « corriger » la dépendance, autrement dit, quand il s’agit des éléments suivants :

  • Dépendances directes déclarées explicitement dans un manifeste ou un fichier de verrouillage

  • Dépendances transitives déclarées dans un fichier de verrouillage

            **Point à vérifier :** la vulnérabilité non interceptée pour un composant qui n’est pas spécifié se trouve-t-elle dans le manifeste ou dans le fichier de verrouillage du dépôt ?

Écosystèmes non pris en charge

          Dependabot alerts sont pris en charge pour un ensemble d’écosystèmes pour lesquels des données exploitables et de haute qualité peuvent être fournies. Les avis sélectionnés dans le GitHub Advisory Database, le graphe de dépendances, les mises à jour de sécurité et Dependabot alerts sont disponibles pour plusieurs écosystèmes, notamment Maven pour Java, npm et Yarn pour JavaScript, NuGet pour .NET, pip pour Python, RubyGems pour Ruby et Composer pour PHP. Pour obtenir une vue d’ensemble des écosystèmes de packages que nous prenons en charge Dependabot alerts, consultez [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/dependency-graph-supported-package-ecosystems#supported-package-ecosystems).

Il est important de noter que des avis de sécurité peuvent exister pour d’autres écosystèmes. Les informations contenues dans un avis de sécurité non révisé sont fournies par les chargés de maintenance d’un dépôt particulier. Ces données ne sont pas organisées par GitHub. Pour plus d’informations, consultez « Exploration des avis de sécurité dans la base de données GitHub Advisory ».

          **Point à vérifier :** la vulnérabilité non interceptée s’applique-t-elle à un écosystème non pris en charge ?

Vulnérabilités historiques

Le GitHub Advisory Database a été lancé en novembre 2019, et a été initialement enrichi pour inclure des alertes sur les risques de sécurité dans les écosystèmes pris en charge, à partir de 2017. Lors de l’ajout de CVE à la base de données, nous organisons en priorité les nouveaux CVE et les CVE qui affectent les versions plus récentes des logiciels.

Certaines informations sur les vulnérabilités plus anciennes sont disponibles, en particulier lorsque ces CVE sont particulièrement répandues, mais certaines anciennes vulnérabilités ne sont pas incluses dans le GitHub Advisory Database. S’il existe une ancienne vulnérabilité spécifique que vous devez inclure dans la base de données, contactez votre administrateur de site.

          **Point à vérifier :** la vulnérabilité non interceptée a-t-elle une date de publication antérieure à 2017 dans la base de données nationale des vulnérabilités ?

Étendue de la base de données de conseil

Certains outils tiers utilisent des données CVE non organisées qui ne sont pas vérifiées ou filtrées par un être humain. Cela signifie que les CVE avec des erreurs d’étiquetage ou de gravité, ou d’autres problèmes de qualité, entraînent des alertes plus fréquentes, plus bruyantes et moins utiles.

Étant donné que Dependabot utilise des données triées dans le GitHub Advisory Database, le volume d’alertes peut être inférieur, mais les alertes que vous recevez seront exactes et pertinentes.

Options d'ignorance des dépendances

Vous pouvez configurer Dependabot pour ignorer des dépendances spécifiques dans le fichier de configuration, ce qui empêchera les mises à jour de sécurité et de version pour ces dépendances. Si vous souhaitez utiliser uniquement des mises à jour de sécurité, vous devez remplacer le comportement par défaut avec un fichier de configuration. Pour plus d’informations, consultez Configuration des mises à jour de sécurité Dependabot pour empêcher l’activation des mises à jour de version. Pour plus d’informations sur comment ignorer les dépendances, consultez Ignorer les dépendances spécifiques.

Limitations du monorepo pour les versions GitHub Actions

Si votre référentiel contient plusieurs GitHub Actions (par exemple, dans un monorepo), le format d’étiquette que vous utilisez influence la façon dont Dependabot détecte et met à jour les versions d’action.

  • Tiret (-) séparateur (par exemple, @my-action-v0.1.0) :

    • Dependabot peut regrouper plusieurs actions sous une seule entrée de dépendance ou ne pas détecter correctement les nouvelles versions. Cela se produit, car Dependabot s’appuie sur l’analyse des balises basée sur des barres obliques pour distinguer les actions.

  • Barre oblique (/) séparatrice (par exemple, @my-action/v0.1.0) :

    •           Dependabot identifie et met à jour correctement chaque action de manière indépendante, la barre oblique instaurant une structure de balises hiérarchique cohérente avec la logique d’analyse de Dependabot.

      **Recommandation :** pour les monorepos avec plusieurs actions, utilisez le format `name/version` (barre oblique) pour les balises d’action. Cela garantit que Dependabot peut analyser correctement la hiérarchie des étiquettes et mettre à jour les actions de manière indépendante.

  • Exemple :

    # Recommended: namespaced with slash
uses: my-org/monorepo/my-action@my-action/v0.1.0

# Not recommended: dash
uses: my-org/monorepo@my-action-v0.1.0

Lectures complémentaires