GitHubの「Automatic Dependabot access to GitHub-hosted registries」は、DependabotがGitHub PackagesやContainer registry上のプライベートパッケージを読むために、個人アクセストークン（PAT）を用意しなくてもよくなる変更です。結論から言うと、GitHub-hosted registriesをDependabotで使っているチームは、Package settingsの「Manage Actions access」にDependabotを実行するリポジトリがRead権限で追加されているかを確認してください。
特に、dependabot.ymlにGitHub Packages向けのPATベースのregistry設定を書いている場合は、設定を簡素化できる可能性があります。一方で、Artifactory、Azure Artifacts、Nexusなどの外部プライベートレジストリは従来どおり認証設定が必要です。GitHub Changelog上では、DependabotがプライベートなGitHub-hosted registriesをPATなしで読み取れるようになったことが案内されています。 (The GitHub Blog)
Automatic Dependabot access to GitHub-hosted registries は何が変わった？
今回の変更により、DependabotはGitHub PackagesやContainer registryに保存されたプライベートパッケージへアクセスする際、GITHUB_TOKENを使って自動的に認証できるようになりました。GitHub Changelogによると、DependabotのGITHUB_TOKENはpackages: readを要求でき、*.pkg.github.comやghcr.ioからパッケージを取得するときにそのトークンを送信します。 (The GitHub Blog)
これまで、DependabotからプライベートなGitHub Packagesを参照するには、dependabot.ymlにregistry設定を書き、Dependabot secretsにPATを登録する運用がよく使われていました。今後は、対象パッケージ側で「Manage Actions access」にリポジトリを追加しておけば、GitHub Actionsワークフローと同じアクセス許可をDependabotも利用できます。 (GitHub Docs)
なお、記事作成時点で確認できるGitHub Changelog上の表示は「Improvement」です。利用者側では、破壊的変更というよりも、Dependabotの認証運用を軽くするリリース相当の改善として捉えると分かりやすいでしょう。
影響を受ける利用者
影響を受けるのは、主に次のようなGitHub利用者です。
| 利用状況 | 確認の必要性 | 理由 |
|---|---|---|
| DependabotでGitHub Packagesのプライベートパッケージを更新している | 高い | PATなしの認証へ移行できる可能性がある |
ghcr.ioのプライベートコンテナイメージをDependabotで参照している | 高い | Container registryも対象に含まれる |
dependabot.ymlにGitHub Packages向けPAT設定がある | 高い | 不要なregistry設定やsecretを削除できる可能性がある |
| 外部レジストリだけを使っている | 低い | Artifactory、Azure Artifacts、Nexusなどは従来の認証設定が必要 |
| パブリックパッケージのみ利用している | 低い | 今回の主な対象はプライベートパッケージへのアクセス |
重要なのは、「GitHubで管理しているパッケージならすべて自動で読める」と考えないことです。Dependabotが読む必要のある各パッケージについて、パッケージ側の設定で対象リポジトリにRead権限が付与されている必要があります。GitHub Docsでも、Dependabotがアクセスする各プライベートパッケージごとに設定を繰り返す必要があると説明されています。 (GitHub Docs)
すぐ確認したい設定
まず確認すべき場所は、dependabot.ymlではなく、GitHub Packages側のアクセス設定です。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Dependabotが読むパッケージ | Organizationまたは個人アカウントのPackagesタブ | プライベートパッケージを使っているか |
| リポジトリのアクセス許可 | Package settings → Manage Actions access | Dependabotを実行するリポジトリが追加されているか |
| 権限レベル | Manage Actions access内のRole | 原則Readで十分 |
| 既存のPAT設定 | .github/dependabot.yml、Dependabot secrets | GitHub Packages向けのPATが残っていないか |
| 外部レジストリ設定 | dependabot.ymlのregistries | 外部レジストリ用の設定を誤って消さないか |
設定手順はシンプルです。Organizationまたは個人アカウントのPackagesタブから対象パッケージを開き、Package settingsに移動します。次に「Manage Actions access」で、Dependabotが動くリポジトリを追加し、RoleをReadにします。GitHub Docsでは、DependabotがパッケージをpullするだけならReadアクセスを選ぶと説明されています。 (GitHub Docs)
ここで間違えやすいのは、パッケージのソースコードがあるリポジトリと、Dependabotが実行されるリポジトリを混同することです。ライブラリを公開しているリポジトリではなく、そのライブラリを依存関係として使っているアプリケーション側のリポジトリでDependabotが動くなら、後者にアクセス権を付与する必要があります。
dependabot.ymlは変更が必要？
GitHub Changelogでは、対象パッケージへのアクセス権を付与すれば、dependabot.ymlの変更は不要で、これらのパッケージ向けに追加していたPATベースのregistry設定は削除できると説明されています。 (The GitHub Blog)
ただし、これは「GitHub-hosted registriesへの認証情報としてのregistry設定が不要になる」という意味です。依存関係がどのレジストリを参照するかは、npm、Maven、NuGet、Dockerなど各エコシステムの設定に依存します。たとえば.npmrc、pom.xml、nuget.config、Dockerfileなどでレジストリ参照が必要なケースまで、すべて自動で書き換わるわけではありません。
移行時は、次の順序で進めると安全です。
| 手順 | 作業 | 失敗を防ぐポイント |
|---|---|---|
| 1 | Dependabotが参照しているGitHub Packagesを洗い出す | dependabot.ymlと各パッケージマネージャーの設定を確認する |
| 2 | Package settingsでManage Actions accessを設定する | Dependabotを実行するリポジトリをReadで追加する |
| 3 | Dependabotの実行結果を確認する | PR作成、ジョブログ、認証エラーの有無を見る |
| 4 | GitHub Packages向けPAT設定を削除する | 外部レジストリ用の設定は残す |
| 5 | 不要になったDependabot secretを削除する | 削除前に他用途で使っていないか確認する |
いきなりPATやsecretを削除すると、設定漏れがあった場合にDependabotの更新が止まります。まずRead権限を付与し、次回のDependabot実行や手動再実行で問題がないことを確認してから、不要な設定を片付けるのが現実的です。
PATベース運用から移行するメリット
今回の変更で最も大きいメリットは、トークン管理の負担を減らせることです。PATを使う場合、発行者の退職、権限過多、有効期限切れ、secretの棚卸し漏れなどが運用上のリスクになります。
Automatic Dependabot accessを使えば、GitHub Packages側のアクセス許可に集約できます。GitHub ActionsとDependabotで同じ「Manage Actions access」の考え方を使えるため、リポジトリ単位で「どのパッケージを読めるか」を確認しやすくなります。
特に、複数チームで共通の社内パッケージを使っているOrganizationでは効果があります。たとえば、共通ライブラリをGitHub Packagesに公開し、複数のアプリケーションリポジトリがDependabotで更新を受け取る場合、各アプリケーションリポジトリを対象パッケージのManage Actions accessにReadで追加すれば、リポジトリごとのPAT配布を避けやすくなります。
注意点：外部レジストリの設定は消さない
今回の対象は、GitHub-hosted registriesです。GitHub Docsでは、GitHub PackagesまたはContainer registryに保存されたパッケージはGITHUB_TOKENで自動認証できる一方、Artifactory、Azure Artifacts、Nexusなどのサードパーティ製プライベートレジストリでは、従来どおりdependabot.ymlのregistry設定が必要だと説明されています。 (GitHub Docs)
つまり、次のように分けて考える必要があります。
| レジストリ | 今回の変更後の考え方 |
|---|---|
ghcr.io | Manage Actions accessでRead権限を付与すればPATなしにできる可能性がある |
*.pkg.github.com | GitHub Packagesとして対象。パッケージごとのアクセス許可を確認する |
| Artifactory | 従来どおり認証設定が必要 |
| Azure Artifacts | 従来どおり認証設定が必要 |
| Nexus | 従来どおり認証設定が必要 |
| Docker Hubなど外部サービス | 従来どおり認証設定が必要なケースがある |
特に、dependabot.ymlに複数のregistry設定がある場合は、「GitHub Packages向け」「外部レジストリ向け」「社内ミラー向け」を分けて棚卸ししてください。GitHub Packages向けのPAT設定だけを削除するつもりで、外部レジストリの認証情報まで消してしまうと、Dependabotが依存関係を解決できなくなります。
運用上の注意点
権限はReadに絞る
Dependabotがパッケージを取得するだけなら、基本的にはRead権限で足ります。WriteやAdminを付与すると、最小権限の原則から外れやすくなります。
パッケージを公開するGitHub Actionsワークフローと、Dependabotがパッケージを読むリポジトリは役割が違います。公開用ワークフローにはWriteが必要な場合がありますが、Dependabotには読み取り権限だけを付けるのが安全です。
パブリックリポジトリに private package のアクセスを付ける場合は慎重にする
GitHub Docsでは、パブリックリポジトリにプライベートパッケージへのアクセスを付与すると、そのリポジトリのforkがプライベートパッケージへアクセスできる可能性があると注意しています。 (GitHub Docs)
OSSリポジトリや外部共同開発者が関わるリポジトリで社内プライベートパッケージを使っている場合は、Manage Actions accessに追加する前に、forkやActions実行ポリシー、pull request運用を確認してください。
パッケージの権限継承を理解する
GitHub Packagesでは、パッケージがリポジトリの権限を継承する場合があります。GitHub Docsでは、リンクされたリポジトリからパッケージがアクセス権限を継承できること、Organization側で自動継承を無効化できることが説明されています。 (GitHub Docs)
そのため、「同じOrganization内なのにDependabotが読めない」という場合は、次の点を確認してください。
- パッケージが対象リポジトリの権限を継承しているか
- Organizationで自動継承が無効化されていないか
- Manage Actions accessに対象リポジトリを明示的に追加しているか
- パッケージが個人アカウント配下かOrganization配下か
- 対象リポジトリが本当にDependabotを実行するリポジトリか
よくある失敗パターン
| 失敗パターン | 起きること | 対策 |
|---|---|---|
| パッケージごとの設定を忘れる | 一部の依存関係だけ取得できない | Dependabotが読む全パッケージを一覧化する |
| ソース側リポジトリだけを追加する | アプリ側のDependabotが認証に失敗する | Dependabotを実行するリポジトリを追加する |
| PATを先に削除する | 次回更新でDependabotが失敗する | アクセス付与後に動作確認してから削除する |
| 外部レジストリ設定まで消す | Artifactoryなどの依存解決に失敗する | GitHub-hosted registriesと外部レジストリを分けて管理する |
| Read以外の権限を付ける | 不要に権限が広がる | 取得専用ならReadに限定する |
| public repoにprivate packageアクセスを付ける | fork経由のアクセスリスクが出る可能性 | リポジトリ公開範囲とfork運用を確認する |
管理者が取るべき次のアクション
GitHub管理者やリポジトリ管理者は、まずDependabotがGitHub Packagesやghcr.ioのプライベートパッケージを参照しているリポジトリを洗い出してください。次に、各パッケージのPackage settingsで「Manage Actions access」を確認し、Dependabotを実行するリポジトリをRead権限で追加します。
その後、Dependabotの実行結果を確認し、問題がなければGitHub Packages向けのPATベースregistry設定や不要になったDependabot secretsを削除します。ただし、外部プライベートレジストリ用の設定は今回の変更対象外です。削除する前に、設定の用途を必ず分けて確認してください。
今回のAutomatic Dependabot access to GitHub-hosted registriesは、Dependabotの認証を大きく変えるというより、GitHub内のパッケージアクセスをより自然に扱えるようにする改善です。確認すべきポイントは多くありません。対象パッケージ、Manage Actions access、Read権限、PAT設定の棚卸しの4点を押さえれば、トークン管理を減らしながら安全に移行できます。
コメント