Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Résolution des problèmes de détection des dépendances vulnérables

Si les informations de dépendance signalées par GitHub Enterprise Server ne sont pas celles que vous attendiez, il y a un certain nombre de points à prendre en compte et plusieurs choses que vous pouvez vérifier.

Les résultats de la détection des dépendances signalés par GitHub Enterprise Server 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.

Pourquoi certaines dépendances semblent-elles manquantes ?

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 que 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 courants sur GitHub. Elle inclut les données signalées directement à GitHub à partir des GitHub Security Advisories ainsi que les flux officiels et les sources communautaires. Ces données sont examinées et organisées GitHub pour s’assurer que les informations fausses ou non exploitables 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 quelle poussée, 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é. Au lieu qu’une alerte soit créée par avis, les Dependabot alerts sont agrégées au niveau du dépôt. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

  • Les Dependabot security updates se déclenchent quand vous recevez une alerte concernant une dépendance vulnérable dans votre référentiel. Dans la mesure du possible, Dependabot crée une demande de tirage (pull request) dans votre dépôt 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 « Résolution des erreurs 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 quand une nouvelle dépendance est ajoutée (GitHub effectue cette vérification à chaque poussée) ou quand un nouvel avis est ajouté à la base de données et synchronisé avec GitHub. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

LesDependabot alerts concernent-elles uniquement les dépendances non sécurisées dans les manifestes et les fichiers de verrouillage ?

Les Dependabot alerts vous fournissent des conseils sur les dépendances à 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. Les Dependabot security updates suggèrent uniquement un changement pour lequel Dependabot peut directement « corriger » la dépendance, c’est-à-dire quand il s’agit de :

  • 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 ?

Pourquoi est-ce que je n’obtiens pas d’Dependabot alerts pour certains écosystèmes ?

Les Dependabot alerts sont prises en charge pour un ensemble d’écosystèmes où nous pouvons fournir des données de haute qualité et exploitables. Les avis organisés dans la GitHub Advisory Database, le graphe de dépendances, et les Dependabot alerts sont fournis pour plusieurs écosystèmes, notamment Maven (Java), npm et Yarn (JavaScript), NuGet (.NET), pip (Python), RubyGems (Ruby) et Composer (PHP). Pour obtenir une vue d’ensemble des écosystèmes de packages que nous prenons en charge pour Dependabot alerts, consultez « Écosystèmes de packages pris en charge pour le graphe des dépendances ».

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 ?

Dependabot génère-t-il des alertes pour les vulnérabilités connues depuis de nombreuses années ?

La GitHub Advisory Database a été lancée en novembre 2019 et dès le départ alimentée pour inclure des avis sur les risques de sécurité pour 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 quand ces CVE sont très répandus, mais certaines anciennes vulnérabilités ne sont pas incluses dans la 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 ?

Pourquoi la GitHub Advisory Database utilise-t-elle un sous-ensemble de données de vulnérabilité publiées ?

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 organisées dans la GitHub Advisory Database, le volume d’alertes peut être inférieur, mais les alertes que vous recevez sont exactes et pertinentes.

Dependabot peut-il ignorer des dépendances spécifiques ?

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 « Options de configuration pour le fichier dependabot.yml ».

Pour aller plus loin