依存関係グラフが依存関係を認識する方法

依存関係グラフでは、マニフェスト ファイルが自動的に分析されます。 自動的に検出できない依存関係のデータを送信できます。

この機能を使用できるユーザーについて

依存関係グラフは、次のリポジトリの種類で使用できます。

  • パブリック リポジトリ (既定ではオン)
  • プライベートリポジトリ
  • フォーク

この記事で

依存関係グラフでは、次のメソッドを使用してプロジェクトの依存関係を識別できます。

メソッドどのように機能するのか
静的分析リポジトリ内のマニフェストとロック ファイルを解析します
**
          Dependabot グラフ ジョブ** | 
          Dependabot
          GitHub Actions ワークフローを使用して依存関係スナップショットを生成する |

| | | | | 自動送信 | 組み込みの GitHub Actions ワークフローを実行して、ビルド時の依存関係を解決する | | | 依存関係送信 API | プログラムで送信した依存関係データを受け入れます |

依存関係がグラフに表示されたら、既知の脆弱性の Dependabot alerts と Dependabot security updates を受け取ることができます。

静的分析

依存関係グラフを有効にすると、 GitHub は、サポートされているマニフェスト ファイルのリポジトリをスキャンし、各パッケージの名前とバージョンを解析します。 グラフは、既定のブランチでサポートされているマニフェストまたはロック ファイルを変更したとき、または依存関係が独自のリポジトリで変更されたときに更新されます。

静的分析では、次の情報を特定できます。

  • マニフェストまたはロック ファイルで明示的に定義された直接の依存関係
  • 間接依存関係—これらの直接依存関係の依存関係は「推移的な依存関係」とも呼ばれますが、これはマニフェストやロックファイルで定義されている場合に限ります。ビルド時に解決される場合は含まれません。

最も信頼性の高いグラフでは、ロック ファイル (またはそれと同等のもの) を使用する必要があります。これは、現在使用している直接的および間接的な依存関係のバージョンを正確に定義するためです。 また、ファイルをロックすると、リポジトリのすべての共同作成者が同じバージョンを使用することが保証されます。これにより、コードのテストとデバッグが容易になります。 さらに、(ロック ファイルではなく) マニフェスト ファイルから推論された間接的な依存関係は、脆弱性チェックから除外されます。

依存関係の自動送信

一部のエコシステムではビルド時に間接的な依存関係が解決されるため、静的分析では完全な依存関係ツリーが表示されません。 リポジトリの依存関係の自動送信を有効にすると、 GitHub は、サポートされているエコシステムのリポジトリ内の推移的な依存関係を自動的に識別します。 「依存関係グラフがサポートされるパッケージ エコシステム」を参照してください。

バックグラウンドで、依存関係の自動送信では、完全なツリーを生成し、GitHub Actionsを使用してアップロードする依存関係送信 API ワークフローが実行されます。 既定では、 GitHubホストランナーに対して依存関係の自動送信が実行され、 GitHub Actions 分にカウントされます。 必要に応じて、セルフホステッド ランナーまたは より大きなランナー (larger runner)で実行することもできます。

依存関係の自動送信を有効にするには、 リポジトリの依存関係の自動送信を構成する を参照してください。

          Dependabot グラフジョブ

          Dependabot グラフ ジョブでは、特殊な種類の Dependabot ジョブを使用して依存関係スナップショットを作成し、依存関係申請 API にアップロードします。 
          Dependabot グラフ ジョブは、 **Go** と **Python** の依存関係で現在サポートされています。

サポートされているエコシステムの場合、 Dependabot グラフ ジョブでは次の機能が提供されます。

  • 完全な推移的な依存関係カバレッジ。つまり、 Dependabot は、静的な分析で見逃す可能性がある間接的な依存関係の脆弱性に対してアラートを生成できます。
  • 組織またはリポジトリ レベルで構成された Dependabot シークレットを介したプライベート レジストリ アクセス。 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」をご覧ください。
  • 構成された Dependabot シークレットを介してアクセスできないプライベート パッケージは、エラーを発生させることなく依存関係グラフから適切に省略されます。

この方法は依存関係の自動送信に似ていますが、GitHub Actions分に対して料金は発生しません。 また、 Dependabot用に設定したプライベート レジストリの組織全体の構成にアクセスすることもできます。

メモ

Dependabot グラフ ジョブは、依存関係の自動送信よりも優先されます。 たとえば、以前に Python リポジトリで依存関係の自動送信が使用されていた場合、グラフ ジョブがアクティブになると、それらのジョブ Dependabot 実行されなくなります。 唯一の要件は、リポジトリに対して依存関係グラフが有効であることです。

          依存関係送信 API

独自のスクリプトまたはワークフローで 依存関係送信 API を呼び出すことができます。 これは、次の場合に役立ちます。

  • ロック ファイルから検出できない推移的な依存関係を送信する必要があります。
  • カスタム ロジックを作成するか、外部 CI/CD システムを使用している必要があります。

依存関係は、スナップショットの形式で 依存関係送信 API に送信されます。 これは、リポジトリの現在の状態を反映した、コミット SHA とその他のメタデータに関連付けられている依存関係の一覧です。

          GitHub Actions ワークフローで API を呼び出す場合は、依存関係を自動的に収集して API に送信するエコシステムに対して事前に作成されたアクションを使用できます。 それ以外の場合は、独自のアクションを記述するか、外部システムから API を呼び出すことができます。

送信された依存関係は依存関係レビューに表示されますが、組織の依存関係インサイトには表示されません。__

メモ

依存関係レビュー API と 依存関係送信 API は連携して動作します。 これは、依存関係レビュー API には、依存関係送信 API を介して送信された依存関係が含まれます。

詳しくは、「依存関係サブミッション API を使用する」をご覧ください。

優先順位付け

リポジトリでは、依存関係の送信に複数のメソッドを使用できます。これにより、同じパッケージ マニフェストが複数回スキャンされる可能性があり、各スキャンからの出力が異なる可能性があります。 依存関係グラフは重複除去ロジックを使って出力を解析し、各マニフェスト ファイルの最も正確な情報を優先します。

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

  1.        **ユーザー送信**は、通常、成果物のビルド中に作成され、最も情報がそろっているため、最優先されます。
    • 異なる detector からの手動スナップショットが複数ある場合、correlator のアルファベット順に並べ替えられ、最初のものが使われます。
    • 同じ検出器を持つ 2 つの相関器がある場合、解決された依存関係はマージされます。 相関子と検出器の詳細については、 依存関係送信用の REST API エンドポイント を参照してください。
  2.        **
       Dependabot グラフ ジョブ** の優先度が 2 番目に高くなります。 
       Dependabotグラフ ジョブが使用可能なエコシステム (現在は Go と Python) では、依存関係の自動送信よりも優先されます。

  3.        **自動送信** は、成果物のビルド中にも作成されますが、ユーザーによって送信されないため、次の優先順位を持ちます。

  4.        **静的分析結果**は、使用できるデータが他にない場合に使われます。