依存関係グラフについて
依存関係グラフの概要については、「依存関係グラフについて」をご覧ください。
依存関係グラフの作成
依存関係グラフは、有効にされると、プログラミング言語パッケージ エコシステムで使われているマニフェスト ファイルをリポジトリでスキャンします。 サポートされているマニフェスト ファイルの 1 つが見つかると、ファイルを解析して、各パッケージの名前とバージョンなど、その内容の表現を作成します。 これは "静的分析" と呼ばれます。
一部のファイルには、すべての直接的およびすべての間接的依存関係に使われるバージョンが明示的に定義されています。 これにより、パッケージのバージョンがビルドに含まれるものに固定されて、Dependabot で直接的と間接的両方の依存関係に含まれる脆弱なバージョンを検出できるようになります。 これらの形式を使うと、依存関係グラフはいっそう正確になるので、[Supported package ecosystems] テーブルの [Recommended files] 列にそれらの一覧が表示されます。 「サポートされているパッケージ エコシステム」をご覧ください。 マニフェスト ファイル (またはそれと同等のもの) から推測される間接的な依存関係は、Dependabot による安全でない依存関係のチェックから除外されます。
ビルド時に推移的な依存関係を解決するエコシステムの場合、静的分析で提供される依存関係ツリーのビューは包括的なものではありません。 このようなエコシステムの場合は、GitHub Actions を使って自動と手動で依存関係を送信する 2 つの方法があります。 どちらの場合も、外部アクションによって完全な依存関係ツリーが生成されて、依存関係送信 API にアップロードされます。 ユーザーは、リポジトリの設定ページで、サポートされているエコシステムの自動送信を有効にできます。 詳しくは、「リポジトリの依存関係の自動送信の構成」をご覧ください。
依存関係の送信アクションによってサポートされるパッケージ エコシステム
依存関係グラフの静的分析と自動送信に加えて、依存関係送信 API を使うと、サポートされるエコシステムの一覧に含まれていないエコシステムの場合でも、ビルド時の依存関係を依存関係グラフに追加することや、ユーザーが任意のパッケージ マネージャーやエコシステムから選んだ依存関係を依存関係グラフに追加することができます。 これらの送信された依存関係からの依存関係情報は、順番に、Dependabot updates と Dependabot alerts に送られます。
依存関係送信 API を使ってプロジェクトに送信された依存関係には、提出にどの検出機能が使われたか、いつ送信されたかが表示されます。依存関係送信 API について詳しくは、「Dependency Submission API を使用する」をご覧ください。
サポートされているパッケージエコシステム
| パッケージ マネージャー | 言語 | 静的な推移的依存関係 | 依存関係の自動送信 | 推奨ファイル | 追加ファイル |
|---|---|---|---|---|---|
| Cargo | Rust | Cargo.lock | Cargo.toml | ||
| Composer | PHP | composer.lock | composer.json | ||
| NuGet | .NET 言語 (C#、F#、VB)、C++ | .csproj、.vbproj、.nuspec、.vcxproj、.fsproj | packages.config | ||
| GitHub Actionsのワークフロー | YAML | .yml、.yaml | |||
| Go モジュール | Go | go.mod | |||
| Gradle | Java | ||||
| Maven | Java、Scala | pom.xml | |||
| npm | JavaScript | package-lock.json | package.json | ||
| pip | Python | requirements.txt, pipfile.lock | pipfile, setup.py | ||
| pnpm | JavaScript | pnpm-lock.yaml | package.json | ||
| pub | Dart | pubspec.lock | pubspec.yaml | ||
| Poetry | Python | poetry.lock | pyproject.toml | ||
| RubyGems | Ruby | Gemfile.lock | Gemfile, *.gemspec | ||
| Swift パッケージ マネージャー | Swift | Package.resolved | |||
| Yarn | JavaScript | yarn.lock | package.json |
メモ
- [Static transitive dependencies] 列は、静的分析によってそのエコシステムの依存パッケージにラベル
directとtransitiveが追加されるかどうかを示します。 依存関係送信アクション (自動または手動構成) では、静的分析ではできないエコシステムに対する推移的情報の追加を行うことができます。 setup.pyファイル内に Python の依存関係を列挙した場合、ユーザーはプロジェクト内のすべての依存関係を解析し、列挙することができない場合があります。- マニフェストとして認識するには、GitHub Actions ワークフローをリポジトリの
.github/workflows/ディレクトリに配置する必要があります。 構文jobs[*].steps[*].usesまたはjobs.<job_id>.usesを使用して参照されるアクションまたはワークフローは、依存関係として解析されます。 詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。 - Dependabot は、セマンティック バージョン管理を使用する脆弱な GitHub Actions に対してのみ、Dependabot alerts を作成します。 SHA バージョン管理を使用する脆弱なアクションのアラートは受け取れません。 SHA バージョン管理で GitHub Actions を使用する場合は、リポジトリまたは組織に対して Dependabot version updates を有効にして、使用するアクションを最新バージョンに更新しておくことをおすすめします。詳細については、「Dependabot アラートについて」と「GitHub Dependabot のバージョンアップデートについて」を参照してください。
マニフェストの重複除去
依存関係グラフは、静的分析、自動送信、手動送信という 3 種類の方法で依存関係を学習できます。 1 つのリポジトリで複数の方法を構成でき、それによって同じパッケージ マニフェストが複数回スキャンされて、スキャンごとに出力が異なる可能性があります。 依存関係グラフは重複除去ロジックを使って出力を解析し、各マニフェスト ファイルの最も正確な情報を優先します。
依存関係グラフには、次の優先順位規則が使われ、各マニフェスト ファイルのインスタンスが 1 つだけ表示されます。
- ユーザー送信は、通常、成果物のビルド中に作成され、最も情報がそろっているため、最優先されます。
- 異なる detector からの手動スナップショットが複数ある場合、correlator のアルファベット順に並べ替えられ、最初のものが使われます。
- detector が同じ correlator が 2 つある場合、解決された依存関係はマージされます。 correlator と detector の詳細については、「依存関係送信用の REST API エンドポイント」を参照してください。
- 自動送信は、成果物のビルド中にも作成されますが、ユーザーによって送信されたものではないため、2 番目に高い優先順位になります。
- 静的分析結果は、使用できるデータが他にない場合に使われます。