依存関係の自動送信

セルフホステッド ランナーのネットワーク アクセスを構成する

ファイアウォール内で外向きのインターネットアクセスが制限されている環境でセルフホステッドランナーを運用する場合、依存関係の自動送信のために特定のURLを許可リスト（ホワイトリスト）に追加する必要があります。 必要な URL は、リポジトリが使用するエコシステムによって異なります。

すべてのエコシステムに必要な URL

すべての自動依存関係送信ワークフローには、次の URL が必要です。

• https://github.com— GitHub へのアクセスとアクションのダウンロードに必要です。
• https://api.github.com— GitHub API アクセスに必要です。
• https://*.githubusercontent.com—アクションのソース コードとリリース ( raw.githubusercontent.com、 github-releases.githubusercontent.com、 objects.githubusercontent.comを含む) をダウンロードするために必要です。

エコシステム固有の URL

使用するエコシステムによっては、追加の URL を許可リストする必要がある場合があります。

Go

• https://go.dev—Go ツールチェーンをダウンロードする場合。
• https://golang.org—Go ダウンロード用の代替ドメイン。
• https://proxy.golang.org—依存関係検出中に Go モジュールをダウンロードするための公式 Go モジュール プロキシ。

Java (Maven と Gradle)

• https://repo.maven.apache.org依存関係をダウンロードするための Maven Central リポジトリ。
• https://api.adoptium.net—Adoptium/Temurin JDK ディストリビューション ( actions/setup-java で使用される既定のディストリビューション) をダウンロードする場合。

Gradle プロジェクトの場合は、Gradle プラグイン ポータルにアクセスする必要もあります。ここで、自動送信アクションによって既定で github-dependency-graph-gradle-plugin がダウンロードされます。

• https://plugins.gradle.org—プラグイン マーカーと maven-metadata.xmlを提供します。
• https://plugins-artifacts.gradle.orgプラグインの POM、モジュール メタデータ、JAR を提供します。 Gradle プラグイン ポータルは成果物のダウンロードをこのホストにリダイレクトするため、許可リスト plugins.gradle.org のみメタデータが解決され、プラグイン成果物がダウンロードされると失敗します。

ランナーが Gradle プラグイン ポータルにアクセスできない場合、または時間の経過と同時に変化する可能性があるホストに応じて回避したい場合は、代わりに制御する内部リポジトリからプラグインを解決します。 詳細については、「 Gradle プロジェクト」を参照してください。

別の JDK ディストリビューションを使用する場合は、次のものが必要になる場合もあります。

• https://aka.ms および https://download.microsoft.com— Microsoft Build of OpenJDKの場合 (注: aka.msは.NETダウンロードにも使用されます)。
• https://download.oracle.com—Oracle JDK。
• https://api.azul.com:Azul Zulu OpenJDK。

.NET (C#、F#、Visual Basic)

• https://aka.ms— .NETのダウンロード場所にリダイレクトするMicrosoftのURL短縮サービス。
• https://builds.dotnet.microsoft.com- .NET SDK とランタイムダウンロードのプライマリ フィード。
• https://ci.dot.net- .NET ビルドのセカンダリ フィード。

Python

• https://python.org- Python インタープリターをダウンロードします。

GitHubホスト型より大きなランナー (larger runner)を使用して依存関係の自動送信を行う

GitHub Team または GitHub Enterprise Cloud ユーザーは、 より大きなランナー (larger runner) を使用して依存関係の自動送信ジョブを実行できます。

1. Organization レベルで、名前が dependency-submission の大規模ランナーをプロビジョニングします。 詳細については、「 組織への より大きなランナー の追加」を参照してください。
2. リポジトリにランナーへのアクセスを許可します。 詳細については、「リポジトリがより大きなランナー (larger runner)にアクセスできるようにする」を参照してください。
3. [依存関係グラフ] で、[依存関係の自動送信] の横にあるドロップダウン メニューを選択し、[ラベル付きランナーで有効] を選びます。

依存関係の自動送信のトラブルシューティング

依存関係の自動送信では、ワークフローを高速化するために、Cache アクションを使用して実行間でパッケージのダウンロードをキャッシュするよう最善を尽くします。 セルフホステッド ランナーの場合、このキャッシュを独自のインフラストラクチャ内で管理することもできます。 これを行うには、環境変数 GH_DEPENDENCY_SUBMISSION_SKIP_CACHE を true に設定して、組み込みキャッシュを無効にできます。 詳しくは、「変数に情報を格納する」をご覧ください。

マニフェストの重複排除

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

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

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

パッケージ エコシステム別の情報

Maven プロジェクト

Maven プロジェクトの場合、依存関係の自動送信では、Maven Dependency Tree Dependency Submission のオープンソースフォークが実行されます。 フォークを使用すると、 GitHub がアップストリーム リポジトリと同期し続け、自動送信にのみ適用される変更を維持できます。 このフォークのソースは advanced-security/maven-dependency-submission-action で確認できます。

リポジトリの依存関係が正確でないように見える場合は、最後に依存関係グラフがビルドされた時刻のタイムスタンプが、pom.xml ファイルへの最後の変更と一致しているかを確認してください。 タイムスタンプは、リポジトリの [ Dependabot ] タブのアラートのテーブルに表示されます。 pom.xml 更新するコミットをプッシュすると、依存関係ツリー送信アクションの新しい実行がトリガーされ、そのリポジトリの依存関係グラフが強制的に再構築されます。

Gradle プロジェクト

Gradle プロジェクトの場合、依存関係を自動的に送信する際には、gradle/actions のオープンソース Gradle アクションのフォークが実行されます。 このフォークは actions/gradle-build-tools-actions で入手できます。 自動送信アクションの結果は、リポジトリの [アクション] タブで確認できます。各実行には「Automatic Dependency Submission (Gradle)」というラベルが付けられ、出力にはアクションが API に送信した JSON ペイロードが含まれます。

内部リポジトリからの申請プラグインの解決

既定では、このアクションは Gradle プラグイン ポータル (https://plugins.gradle.org) からgithub-dependency-graph-gradle-pluginをダウンロードします。 制限付きネットワーク上のセルフホステッド ランナーの場合、プライベート Artifactory インスタンスや Nexus インスタンスなど、制御する内部リポジトリでプラグインをホストする方が、ホストと CDN が時間の経過とともに変化する可能性があるポータルの許可リストよりも信頼性が高くなります。 次の環境変数を使用して、内部リポジトリでアクションをポイントできます。

• GRADLE_PLUGIN_REPOSITORY_URL—プラグインを解決する内部リポジトリの URL。
• GRADLE_PLUGIN_REPOSITORY_USERNAME と GRADLE_PLUGIN_REPOSITORY_PASSWORD— 資格情報 (リポジトリで認証が必要な場合)。

依存関係の自動送信では、リポジトリで作成したワークフローではなく、 GitHub が管理するワークフローが実行されるため、 env: ブロックを追加することはできません。 これらの変数はランナーに設定できますが、そのランナーでスケジュールされたすべてのジョブは、依存関係の自動送信ジョブだけでなく、それらを継承します。

内部リポジトリで匿名読み取りアクセスが許可されている場合は、 GRADLE_PLUGIN_REPOSITORY_URL を設定するだけで済み、資格情報変数を完全に省略できるため、この問題は回避できます。 リポジトリで認証が必要な場合は、読み取り専用資格情報と専用ランナーを使用します。 また、組織レベルまたはエンタープライズ レベルのランナーの場合は、これらの資格情報を必要とするリポジトリのみにランナー グループアクセスを制限します。 「グループを使用してセルフホストランナーへのアクセスを管理する」を参照してください。

内部リポジトリからプラグインを解決することは、ビルドが独自の依存関係を解決する方法 (内部レジストリを指す init.gradle ファイルなど) の構成とは別です。 これらの変数は、依存関係申請プラグインのダウンロード先のみを制御します。

最新の構成の詳細については、 actions/gradle-build-tools-actions の ドキュメントを参照してください。

.NET プロジェクト

.NETの自動送信アクションでは、依存関係検出のエンジンとして オープンソース component-detection プロジェクトが使用されます。 .NET 8.x、9.x、および 10.x がサポートされています。 .NET自動送信は、リポジトリのdependabot.ymlでnugetがpackage-ecosystemとして定義されている場合、またはリポジトリのルートディレクトリにサポートされているマニフェストファイルがある場合に実行されます。 サポートされているマニフェスト ファイルには、.sln、.csproj、packages.config、.vbproj、.vcxproj、.fsproj などがあります。

Python プロジェクト

依存関係グラフが有効になっている Python リポジトリでは、 Dependabot グラフ ジョブを使用して依存関係グラフを生成します。 Dependabot グラフ ジョブは自動依存関係の送信よりも優先され、以下で説明する自動提出ワークフローは Python プロジェクトでは実行されなくなります。 詳しくは、「依存関係グラフが依存関係を認識する方法」をご覧ください。

Python の依存関係の自動送信では、基になるグラフ生成エンジンとしてオープン ソース コンポーネント検出 プロジェクトが使用されます。 自動送信アクションは、リポジトリのルート ディレクトリに requirements.txt ファイルがある場合にのみ実行されます。 自動送信Pythonプライベート パッケージは現在サポートされていません。requirements.txt で参照されているパッケージが一般公開されていない場合、自動送信アクションは失敗します。