How the dependency graph recognizes dependencies

The dependency graph can identify your project's dependencies using the following methods.

Method	How it works
Static analysis	Parses manifest and lock files in your repository
Dependabot graph jobs	Uses a Dependabot GitHub Actions workflow to generate dependency snapshots
Automatic submission	Runs a built-in GitHub Actions workflow to resolve build-time dependencies
API de soumission de dépendances	Accepts dependency data you submit programmatically

Once dependencies are in the graph, you can receive Dependabot alerts and Dependabot security updates for any known vulnerabilities.

Static analysis

When you enable the dependency graph, GitHub scans your repository for supported manifest files and parses each package's name and version. The graph updates when you change a supported manifest or lock file on your default branch, or when a dependency changes in its own repository.

Static analysis can identify:

• Direct dependencies explicitly defined in a manifest or lock file
• Indirect dependencies—dependencies of these direct dependencies, also called "transitive dependencies"—but only if they are defined in a manifest or lock file, not if they are resolved at build time

For the most reliable graph, you should use lock files (or their equivalent), because they define exactly which versions of the direct and indirect dependencies you currently use. Lock files also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code. In addition, indirect dependencies inferred from manifest files (rather than lock files) are excluded from vulnerability checks.

Automatic dependency submission

Some ecosystems resolve indirect dependencies at build time, so static analysis can't see the full dependency tree. When you enable automatic dependency submission for a repository, GitHub automatically identifies the transitive dependencies in the repository for supported ecosystems. See Écosystèmes de packages pris en charge pour le graphe des dépendances.

In the background, automatic dependency submission runs a GitHub Actions workflow that generates the complete tree and uploads it using the API de soumission de dépendances. Automatic dependency submission runs on GitHub-hosted runners by default and counts toward your GitHub Actions minutes. Optionally, you can choose to run it on self-hosted runners or exécuteurs plus grands.

To enable automatic dependency submission, see Configuration de l’envoi automatique des dépendances pour votre dépôt.

Dependabot graph jobs

This method uses a special type of Dependabot job that builds a dependency snapshot and uploads it to the dependency submission API. This is currently only supported for Go dependencies.

This approach is similar to automatic dependency submission, but does not incur charges for GitHub Actions minutes. It can also access organization-wide configurations for private registries you've set up for Dependabot.

The API de soumission de dépendances

You can call the API de soumission de dépendances in your own script or workflow. This is useful if:

• You need to submit transitive dependencies that cannot be detected from lock files.
• You need to create custom logic or are using an external CI/CD system.

Dependencies are submitted to the API de soumission de dépendances in the form of a snapshot. This is a list of dependencies associated with a commit SHA and other metadata, reflecting the current state of your repository.

If you are calling the API in a GitHub Actions workflow, you can use a pre-made action for your ecosystem that automatically gathers the dependencies and submits them to the API. Otherwise, you can write your own action or call the API from an external system.

Vous pouvez utiliser l’API REST pour envoyer des dépendances pour un projet. Cela vous permet d’ajouter des dépendances, comme celles résolues quand le logiciel est compilé ou généré, au graphique de dépendance GitHub, pour une vue d’ensemble plus complète de l’ensemble des dépendances de votre projet.

Le graphique de dépendances affiche les dépendances que vous envoyez à l’aide de l’API, en plus des dépendances identifiées à partir de fichiers manifeste ou de verrouillage dans le référentiel (par exemple un fichier package-lock.json dans un projet JavaScript). Pour plus d’informations sur l’affichage du graphe des dépendances, consultez Exploration des dépendances d’un dépôt.

Les dépendances envoyées reçoivent des Dependabot alerts et Dependabot security updates pour toutes les vulnérabilités connues. Vous ne recevrez des Dependabot alerts que pour les dépendances provenant de l’un des écosystèmes pris en charge pour la GitHub Advisory Database. Pour plus d'informations sur ces écosystèmes, voir À propos de la base de données GitHub Advisory. Pour les dépendances transitives soumises via l’API API de soumission de dépendances, Dependabot ouvre automatiquement les demandes de tirage (pull requests) pour mettre à jour la dépendance parente, si une mise à jour est disponible.

Les dépendances soumises seront affichées dans la revue des dépendances, mais ne sont pas disponibles dans les insights de dépendance de votre organisation.

For more information, see Utilisation de l’API de soumission de dépendances.

Prioritization

Le graphe des dépendances peut découvrir les dépendances de trois manières différentes : analyse statique, soumission automatique et soumission manuelle. Un référentiel peut avoir plusieurs méthodes configurées, ce qui peut entraîner l’analyse multiple du même manifeste de package, avec des sorties potentiellement différentes à chaque analyse. Le graphe des dépendances utilise une logique de déduplication pour analyser les sorties, en donnant la priorité aux informations les plus précises pour chaque fichier manifeste.

Le graphe des dépendances affiche uniquement une instance de chaque fichier manifeste à l’aide des règles de priorité suivantes.

1. Les soumissions des utilisateurs ont la priorité absolue, car elles sont généralement créées lors de la génération des artefacts et contiennent donc les informations les plus complètes.
   • S’il existe plusieurs instantanés manuels provenant de différents détecteurs, ils sont classés par ordre alphabétique selon le corrélateur et le premier est utilisé.
   • S’il existe deux corrélateurs avec le même détecteur, les dépendances résolues sont fusionnées. Pour plus d’informations sur les corrélateurs et les détecteurs, consultez Points de terminaison d’API REST pour la soumission de dépendances.
2. Les soumissions automatiques ont la deuxième priorité la plus élevée, car elles sont également créées lors de la génération des artefacts, mais ne sont pas soumises par les utilisateurs.
3. Les résultats de l’analyse statique sont utilisés lorsqu’aucune autre donnée n’est disponible.