Skip to main content

Enterprise Server 3.15 は、現在リリース候補として使用できます。

依存関係の確認について

依存関係のレビューを使うと、安全でない依存関係を自分の環境に持ち込んでしまう前に捉え、ライセンス、依存物、依存関係の期間に関する情報を確認できます。

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

GitHub Advanced Security が有効になっている組織所有のリポジトリ

依存関係の確認について

依存関係レビューを使うと、すべてのPull Reqeustにおける以下の変更による依存関係の変化とセキュリティについての影響を理解しやすくなります。pull request の [Files Changed](変更されたファイル) タブ上のリッチ diff で依存関係の変更をわかりやすく視覚化できます。 依存関係レビューは、以下のことを知らせます:

  • リリース日と合わせて、追加、削除、更新された依存関係。
  • これらのコンポーネントを使うプロジェクトの数。
  • これらの依存関係に関する脆弱性のデータ。

パッケージ マニフェストまたはロックされたファイルへの変更が含まれている場合は、依存関係のレビューを表示して、何が変更されたかを確認できます。 依存関係のレビューには、ロックファイル内の間接的な依存関係への変更の詳細が含まれ、追加または更新された依存関係のいずれかに既知の脆弱性が含まれているかどうかが示されます。

時に、マニフェスト内の 1 つの依存関係のバージョンを更新して、プルリクエストを生成することがあります。 ただし、この直接依存関係の更新バージョンでも依存関係が更新されている場合は、プルリクエストに予想よりも多くの変更が加えられている可能性があります。 各マニフェストとロックファイルの依存関係のレビューにより、何が変更されたか、新しい依存関係バージョンのいずれかに既知の脆弱性が含まれているかどうかを簡単に確認できます。

プルリクエストで依存関係のレビューを確認し、脆弱性としてフラグが付けられている依存関係を変更することで、プロジェクトに脆弱性が追加されるのを防ぐことができます。 依存関係レビューのしくみについて詳しくは、「プルリクエスト内の依存関係の変更をレビューする」をご覧ください。

依存関係レビューの構成方法について詳しくは、「依存関係レビューの構成」をご覧ください。

Dependabot alerts は、すでに依存関係にある脆弱性を検出しますが、あとで修正するよりも、潜在的な問題が持ち込まれることを回避する方がはるかに良いです。 Dependabot alerts について詳しくは、「Dependabot アラートについて」をご覧ください。

依存関係のレビューは、依存関係グラフと同じ言語とパッケージ管理エコシステムをサポートしています。 詳しくは、「依存関係グラフでパッケージ エコシステムをサポート」を参照してください。

GitHub Enterprise Server で利用できるサプライ チェーン機能について詳しくは、「サプライ チェーンのセキュリティについて」をご覧ください。

依存関係レビューを有効にする

依存関係グラフを有効にすると、依存関係レビューが使用できるようになります。 詳細については、「エンタープライズの依存関係グラフの有効化」を参照してください。

依存関係レビューの適用

このアクションは、GitHub Advanced Security が有効になっているすべてのリポジトリで使用できます。

組織の所有者は、組織内のリポジトリ全体で 依存関係レビュー アクション の使用を実施することで、依存関係レビューを大規模にロールアウトできます。 これには、必要なワークフローとして 依存関係レビュー アクション を設定するためのリポジトリ ルールセットの使用が含まれます。つまり、pull requestは、ワークフローが必要なすべてのチェックに合格した後にのみ統合できます。 詳しくは、「組織全体で依存関係レビューを実施する」を参照してください。

Enterprise 所有者とリポジトリへの管理者アクセス権を持つユーザーは、それぞれ Enterprise とリポジトリに 依存関係レビュー アクション を追加できます。

リポジトリの dependency-review-action を使用して pull request に依存関係レビューを実施できます。 このアクションは、pull request のパッケージ バージョンの変更によって発生した依存関係の脆弱なバージョンをスキャンし、関連するセキュリティの脆弱性について警告します。 これにより、pull request で何が変更されているかをより正確に把握でき、リポジトリに脆弱性が追加されるのを防ぐことができます。

依存関係レビュー アクションを使用するワークフロー実行のスクリーンショット。

既定では、脆弱性のあるパッケージが検出された場合、依存関係レビュー アクション チェックは失敗します。 リポジトリの所有者が依存関係レビューのチェックに合格することを要求している場合、チェックが失敗すると pull request のマージがブロックされます。 詳しくは、「保護されたブランチについて」を参照してください。

このアクションでは、依存関係レビュー REST API を使用して、ベース コミットとヘッド コミット間での依存関係変更の差分が取得されます。 依存関係レビュー API を使用すると、リポジトリ上の 2 つのコミット間で、依存関係の変更の差分 (脆弱性データを含む) を取得できます。 詳細については、「依存関係レビュー用の REST API エンドポイント」を参照してください。このアクションでは、依存関係送信 API を介して送信された依存関係も考慮されます。 依存関係送信 API の詳細については、「Dependency Submission API を使用する」を参照してください。

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

ニーズに合うように 依存関係レビュー アクション を構成できます。 たとえば、アクションが失敗する重大度レベルを指定できます。 詳しくは、「依存関係レビューの構成」を参照してください。

依存関係レビュー API と 依存関係送信 API を一緒に使用するためのベスト プラクティス

依存関係レビュー API と 依存関係レビュー アクション はどちらも、pull request の依存関係の変更と、ターゲット ブランチのヘッド コミットの依存関係の状態を比較することで機能します。

リポジトリが GitHub がサポートするエコシステムのひとつで静的に定義された依存関係にのみ依存している場合、依存関係レビュー API と 依存関係レビュー アクション は一貫して動作します。

ただし、ビルド中に依存関係をスキャンし、依存関係送信 API にアップロードしたい場合があります。 この場合、データが不足する可能性があるため、依存関係レビュー API と 依存関係送信 API のプロセスを実行するときに競合状態が発生しないようにするために従う必要があるベスト プラクティスがいくつかあります。

実行する必要があるベスト プラクティスは、GitHub Actions を使用して 依存関係送信 API と依存関係レビュー API にアクセスするか、直接 API アクセスを使用するかによって異なります。

GitHub Actions を使用して 依存関係送信 API と依存関係レビュー API にアクセスします

GitHub Actions を使用して 依存関係送信 API または依存関係レビュー API にアクセスする場合:

  • すべての依存関係の送信アクションを、依存関係レビュー アクション と同じ GitHub Actions ワークフローで実行していることを確認してください。 これにより、実行順序を制御でき、依存関係の確認が常に機能するようになります。
  • 依存関係レビュー アクション を個別に実行する場合は、次の操作を実行します。
    • retry-on-snapshot-warningstrue に設定します。
    • 実行時間が最も長い依存関係の送信アクションの一般的な実行時間 (秒単位) をretry-on-snapshot-warnings-timeoutわずかに超える値に設定します。

依存関係送信 API と依存関係レビュー API への直接 API アクセスの使用

GitHub Actions を使用せず、依存関係送信 API と依存関係レビュー API への直接アクセスに依存するコードの場合:

  • まず 依存関係送信 API を呼び出すコードを実行してから、後で依存関係レビュー API を呼び出すコードを実行してください。
  • 依存関係送信 API と依存関係レビュー API のコードを並列で実行する場合は、再試行ロジックを実装し、次の点に注意してください。
    • 比較の両側にスナップショットが見つからない場合は、x-github-dependency-graph-snapshot-warnings ヘッダーにその説明が表示されます (base64 でエンコードされた文字列として)。 そのため、ヘッダーが空でない場合は、再試行を検討する必要があります。
    • 指数バックオフを使用して 再試行を実装します。
    • 依存関係の送信コードの一般的なランタイムを考慮して、妥当な回数の再試行を実装します。

参考資料