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	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 依存関係グラフがサポートされるパッケージ エコシステム.

In the background, automatic dependency submission runs a GitHub Actions workflow that generates the complete tree and uploads it using the 依存関係送信 API. 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 より大きなランナー (larger runner).

To enable automatic dependency submission, see リポジトリの依存関係の自動送信を構成する.

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

You can call the 依存関係送信 API 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 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.

REST API を使って、プロジェクトの依存関係を送信できます。 これにより、ソフトウェアのコンパイル時やビルド時に解決されるものなどの依存関係を GitHub の依存関係グラフ機能に追加し、プロジェクトのすべての依存関係をより完全に把握できます。

依存関係グラフには、リポジトリ内のマニフェストまたはロック ファイル (JavaScript プロジェクトの package-lock.json ファイルなど) から識別された依存関係に加えて、この API を使って送信したすべての依存関係が表示されます。 依存関係グラフの表示の詳細については、「リポジトリの依存関係を調べる」を参照してください。

送信された依存関係は、既知の脆弱性に対する Dependabot alerts と Dependabot security updates を受け取ります。 GitHub Advisory Database のサポートされているエコシステムのいずれかからの依存関係に対する Dependabot alerts のみを受け取ります。 これらのエコシステムの詳細については、「GitHub Advisory Database について」を参照してください。 依存関係送信 API を介して送信された推移的な依存関係の場合、更新プログラムが利用可能な場合は、Dependabot が自動的に pull request を開き、親依存関係を更新します。

送信された依存関係は依存関係レビューに表示されますが、organization の依存関係の分析情報には表示 "されません"。__

For more information, see 依存関係サブミッション API を使用する.

Prioritization

依存関係グラフは、静的分析、自動送信、手動送信という 3 種類の方法で依存関係を学習できます。 1 つのリポジトリで複数の方法を構成でき、それによって同じパッケージ マニフェストが複数回スキャンされて、スキャンごとに出力が異なる可能性があります。 依存関係グラフは重複除去ロジックを使って出力を解析し、各マニフェスト ファイルの最も正確な情報を優先します。

依存関係グラフには、次の優先順位規則が使われ、各マニフェスト ファイルのインスタンスが 1 つだけ表示されます。

1. ユーザー送信は、通常、成果物のビルド中に作成され、最も情報がそろっているため、最優先されます。
   • 異なる detector からの手動スナップショットが複数ある場合、correlator のアルファベット順に並べ替えられ、最初のものが使われます。
   • detector が同じ correlator が 2 つある場合、解決された依存関係はマージされます。 correlator と detector の詳細については、「依存関係送信用の REST API エンドポイント」を参照してください。
2. 自動送信は、成果物のビルド中にも作成されますが、ユーザーによって送信されたものではないため、2 番目に高い優先順位になります。
3. 静的分析結果は、使用できるデータが他にない場合に使われます。