GitHubの「Automatic Dependabot access to GitHub-hosted registries」は、GitHub PackagesやContainer registryにあるプライベートパッケージへ、DependabotがPersonal Access Tokenなしでアクセスできるようにする変更です。管理者が最初に確認すべき結論は、対象パッケージの「Manage Actions access」でDependabotを実行するリポジトリにRead権限が付与されているか、そして既存のPATベース設定を安全に整理できるかの2点です。
この変更により、dependabot.ymlにGitHubホスト型レジストリ向けの認証情報を持たせる必要が減り、トークン管理の負担を下げられます。一方で、パッケージ側の権限設定がそのままDependabotの読み取り可否に影響するため、GitHub管理者はリポジトリ、パッケージ、Actions権限、監査ログ、開発チームへの周知をセットで確認する必要があります。GitHub Changelogでは、DependabotがプライベートなGitHub PackagesレジストリをPersonal Access Tokenなしで読み取れるようになり、「Manage Actions access」でリポジトリに付与された権限を再利用すると説明されています。(The GitHub Blog)
Automatic Dependabot access to GitHub-hosted registries とは
Automatic Dependabot access to GitHub-hosted registriesは、DependabotがGitHub上でホストされているパッケージレジストリへアクセスする際の認証方法を簡素化する変更です。
従来は、GitHub Packages上のプライベートパッケージをDependabotで更新対象にする場合、dependabot.ymlにregistries設定を書き、Dependabot secretsなどでPersonal Access Tokenを渡す構成がよく使われていました。今回の変更では、DependabotのGITHUB_TOKENがpackages: readを要求できるようになり、*.pkg.github.comやghcr.ioから取得する際にそのトークンが使われます。パッケージ側で対象リポジトリに「Manage Actions access」のRead権限が付いていれば、通常のGitHub Actionsワークフローと同じ考え方でDependabotが読み取れるようになります。(The GitHub Blog)
管理者視点では、「Dependabotの設定変更」だけでなく、「GitHub Packagesのアクセス制御変更」として扱うのが適切です。
なお、指定された発表内容について、GitHub Changelogの該当ページでは日付は2026年6月23日、分類は「Improvement」と表示されています。日本時間や社内告知日として2026年6月24日扱いにする場合でも、社内資料では「GitHub Changelog上の表示」と「社内での確認日」を分けて書くと混乱を避けられます。(The GitHub Blog)
管理者が最初に確認すべき影響範囲
この変更の影響を受けるのは、主に次の条件に当てはまる組織です。
| 確認項目 | 影響を受ける可能性 | 管理者が見るべきポイント |
|---|---|---|
| GitHub Packagesを使っている | 高い | npm、Maven、NuGet、RubyGems、Container registryなどを使っているか |
ghcr.ioのプライベートコンテナイメージを使っている | 高い | Dockerfile、Helm、CI/CD、Dependabotの更新対象に含まれるか |
| Dependabotでプライベート依存関係を更新している | 高い | dependabot.ymlにregistries設定やPAT参照があるか |
| GitHub Actionsからパッケージを取得している | 中〜高 | 「Manage Actions access」でリポジトリにRead権限が付いているか |
| PATの棚卸しが不十分 | 高い | 退職者・共用アカウント・期限なしトークンが残っていないか |
特に注意したいのは、GitHub Actionsでは問題なくパッケージを取得できているのに、Dependabotだけ失敗していた環境です。今回の変更により、同じ「Manage Actions access」の許可をDependabotも利用できるため、設定を整理できる可能性があります。GitHub Docsでも、GitHub PackagesまたはContainer registryに保存されたパッケージについて、DependabotはGITHUB_TOKENで自動認証でき、この方法ではPATやdependabot.ymlのレジストリエントリが不要と説明されています。(GitHub Docs)
変更前後の違いを整理する
管理者向けに説明するなら、「Dependabot用の特別なPAT管理」から「パッケージ側のリポジトリアクセス管理」へ軸が移る、と表現すると分かりやすいです。
| 観点 | 変更前の典型構成 | 変更後の確認ポイント |
|---|---|---|
| 認証方法 | PATをDependabot secretsに登録 | DependabotのGITHUB_TOKENを利用 |
| 設定場所 | dependabot.ymlとSecrets | パッケージ設定の「Manage Actions access」 |
| 権限管理 | PAT所有者・スコープ・期限の管理が必要 | パッケージに対するリポジトリのRead権限を管理 |
| 監査対象 | PAT作成、Secret変更、Dependabot設定変更 | パッケージ権限、リポジトリ権限、Dependabot実行結果 |
| リスク | 過剰スコープのPAT、期限切れ、所有者不明 | 不要なリポジトリにRead権限を付けたままにする |
この変更は、セキュリティを自動的に強化してくれる魔法の機能ではありません。PATを減らせる点は大きなメリットですが、パッケージアクセス権限の棚卸しをしないまま有効化すると、不要なリポジトリがプライベートパッケージを読める状態を見落とす可能性があります。
権限確認のチェックリスト
Automatic Dependabot access to GitHub-hosted registriesで最も重要なのは、パッケージ単位のアクセス権限です。GitHubのパッケージ設定では、GitHub Actionsワークフローにパッケージアクセスを許可するため、パッケージの「Manage Actions access」からリポジトリを追加し、アクセスレベルを選択できます。GitHub Docsでは、このアクセス付与によりDependabotもPATやdependabot.ymlのレジストリ設定なしでパッケージをpullできると説明されています。(GitHub Docs)
確認すべき権限
| 対象 | 推奨確認内容 | 判断基準 |
|---|---|---|
| パッケージ | 「Manage Actions access」に対象リポジトリがあるか | Dependabotを実行するリポジトリだけを追加する |
| 権限レベル | Read、Write、Adminのどれか | Dependabotの取得用途なら原則Read |
| リポジトリ | Dependabotが有効か | Version updates、Security updatesの対象か確認 |
| Organization設定 | パッケージ権限の継承設定 | 自動継承を使うか、個別管理するかを決める |
| 公開リポジトリ | private packageへのアクセスを与えていないか | public repoにprivate packageを許可する場合は慎重に判断 |
GitHub Docsでは、Read権限はパッケージのダウンロードとメタデータ読み取り、Write権限はアップロードとダウンロード、Admin権限は削除や権限管理まで含むと説明されています。Dependabotが依存関係を解決する目的であれば、基本はRead権限で十分です。(GitHub Docs)
publicリポジトリにprivate packageを許可する場合の注意
特に見落としやすいのが、publicリポジトリにprivate packageのアクセスを付けるケースです。GitHub Docsでは、publicリポジトリにprivate packagesへのアクセスを付与すると、フォークがprivate packagesへアクセスできる可能性があると注意されています。(GitHub Docs)
社内OSS風に公開しているリポジトリ、サンプルコード用リポジトリ、採用課題用リポジトリなどに、社内専用パッケージへのRead権限を付ける場合は、Dependabotの利便性よりも情報露出リスクを優先して判断してください。
管理者向けの確認手順
まずは全体適用ではなく、影響が大きいリポジトリから段階的に確認するのが安全です。
| 手順 | 作業内容 | 完了条件 |
| -: | ————————————– | ———————————– |
| 1 | GitHub Packagesを使っているOrganizationを洗い出す | 対象Orgとパッケージ一覧がある |
| 2 | Dependabotが有効なリポジトリを抽出する | dependabot.ymlの有無と対象ecosystemが分かる |
| 3 | dependabot.yml内のregistries設定を確認する | GitHubホスト型レジストリ向けPAT設定を特定できる |
| 4 | パッケージの「Manage Actions access」を確認する | 対象リポジトリにRead権限がある |
| 5 | Dependabotの実行結果を確認する | private package取得エラーが解消している |
| 6 | 不要になったPAT設定を削除する | PR、レビュー、ロールバック手順付きで削除できる |
| 7 | 監査ログと運用ルールを更新する | 変更者、変更日、対象パッケージを追跡できる |
GitHubの公式手順では、Dependabotが読み取る必要がある各パッケージについて、Organizationまたは個人アカウントのPackagesタブからパッケージ設定を開き、「Manage Actions access」でDependabotを実行するリポジトリをRead権限で追加します。公式発表では、この場合dependabot.ymlの変更は不要で、これらのパッケージ用に追加していたPATベースのregistry entriesを削除できると説明されています。(The GitHub Blog)
dependabot.ymlの移行判断
既存のdependabot.ymlをすぐに削除するのではなく、まず「何のためのregistry設定か」を分類してください。
削除候補になる設定
次のような設定は、今回の変更により削除候補になります。
version: 2
registries:
npm-github:
type: npm-registry
url: https://npm.pkg.github.com
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
updates:
- package-ecosystem: "npm"
directory: "/"
registries:
- npm-github
schedule:
interval: "weekly"この例では、GitHub Packages上のnpmパッケージにPATでアクセスしています。対象パッケージの「Manage Actions access」でこのリポジトリにRead権限を付け、Dependabotが正常に動くことを確認できれば、PATベースのregistry設定を減らせます。
残すべき設定
一方で、次のような設定は安易に削除してはいけません。
| 設定の種類 | 削除してはいけない理由 |
|---|---|
| AWS ECR、Artifactory、Nexus、Azure Artifactsなど外部レジストリ | 今回の対象はGitHubホスト型レジストリではない |
| 社内ネットワーク内のプライベートレジストリ | 別途認証やself-hosted runner構成が必要になる場合がある |
| GitHub以外のnpm、Maven、NuGetフィード | GitHubのGITHUB_TOKENでは認証できない |
| 複数レジストリを明示的に切り替える設定 | 依存解決順序やreplaces-baseに影響する可能性がある |
GitHub Docsでも、第三者または外部のプライベートレジストリについては、Organizationレベルのレジストリ設定やdependabot.ymlのregistriesキーで認証情報を設定できると説明されています。今回の変更は、すべてのプライベートレジストリ認証を不要にするものではありません。(GitHub Docs)
監査ログで確認すべきポイント
Automatic Dependabot access to GitHub-hosted registriesを導入する際は、「Dependabotが読めるようになったか」だけでなく、「誰が、どのパッケージに、どのリポジトリのアクセスを付けたか」を追跡できる状態にしておくことが重要です。
GitHubのOrganization監査ログでは、メンバーが行った操作について、誰が、何を、いつ行ったかなどの情報を確認できます。また、監査ログはaction、actor、repo、createdなどの条件で絞り込みできます。(GitHub Docs)
確認時は、少なくとも次の観点でログを見ます。
| 監査観点 | 検索・確認の例 | 目的 |
|---|---|---|
| パッケージ関連操作 | action:packages | パッケージ公開・削除などの操作を確認 |
| 対象リポジトリ | repo:org-name/repo-name | Dependabot実行リポジトリ周辺の変更を確認 |
| 変更者 | actor:username | 権限変更を行った担当者を確認 |
| 期間 | created:2026-06-24..2026-07-31 | 変更適用期間の操作を確認 |
| PAT関連 | action:personal_access_token | PAT棚卸しやアクセス許可の変更を確認 |
Organizationの監査ログイベント一覧では、packagesカテゴリにパッケージの公開、削除、バージョン公開、バージョン削除などのイベントが含まれています。パッケージ権限変更そのものの見え方はGitHubの画面やプラン、時点によって差が出る可能性があるため、実運用では監査ログの検索結果、パッケージ設定画面、変更申請チケットを突き合わせて管理するのが安全です。(GitHub Docs)
セキュリティ上のメリットと注意点
今回の変更は、トークン管理の観点では前向きな変更です。PATを減らせれば、期限切れ、過剰スコープ、所有者不明、退職者アカウント依存といった運用リスクを下げられます。
ただし、次の点は必ず確認してください。
メリット
- Dependabot専用のPATを作らずに済む場面が増える
dependabot.ymlにレジストリ認証情報を持たせる必要が減る- GitHub ActionsとDependabotのアクセス管理を「Manage Actions access」に寄せられる
- PATローテーション漏れによるDependabot失敗を減らせる
- 依存関係更新の自動化をプライベートパッケージにも広げやすい
注意点
- パッケージ側でRead権限を付け忘れるとDependabotは取得に失敗する
- 不要なリポジトリにRead権限を付けると、private packageの露出範囲が広がる
- publicリポジトリにprivate packageアクセスを付ける場合はフォークの影響を考慮する
- 外部レジストリ向けの
registries設定は引き続き必要になる場合がある - PAT設定を削除する前に、Dependabotの実行結果を確認する必要がある
「PATが不要になったから安全」ではなく、「PATを減らしたうえで、パッケージのRead権限を最小化する」ことが管理者のゴールです。
移行時に失敗しやすいポイント
パッケージとリポジトリの関係を誤解する
GitHub Packagesでは、パッケージがリポジトリの権限を継承する場合と、パッケージ単独で権限を管理する場合があります。GitHub Docsでは、リポジトリにリンクされたパッケージは既定でリンク先リポジトリのアクセス権限を継承し、継承している場合はリンク先リポジトリの権限設定でアクセスを管理すると説明されています。(GitHub Docs)
「ソースコードのリポジトリ」と「Dependabotを実行するリポジトリ」が別の場合は、特に注意が必要です。パッケージを作っているリポジトリではなく、Dependabotが動くリポジトリにアクセス権限が必要になるケースがあります。
dependabot.ymlを一括削除してしまう
GitHubホスト型レジストリ向けのPAT設定は削除候補になりますが、外部レジストリ向け設定まで削除すると、Dependabotが依存関係を解決できなくなる可能性があります。
移行時は、次のようにコメント付きPRで段階的に進めると安全です。
# 削除候補: GitHub Packages向けPAT設定
# 削除前に、対象packageのManage Actions accessでこのrepoにRead権限があることを確認する
registries:
npm-github:
type: npm-registry
url: https://npm.pkg.github.com
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}削除PRには、対象パッケージ、対象リポジトリ、確認したDependabot実行結果、ロールバック方法を記載しましょう。
権限をWriteやAdminで付けてしまう
Dependabotがパッケージを取得するだけなら、原則Readで足ります。WriteやAdminを付けると、パッケージの更新、削除、権限管理に関わるリスクが広がります。
例外的にWriteやAdminが必要な運用がある場合でも、Dependabotのためではなく、別のGitHub Actionsワークフローのために必要なのかを切り分けてください。
開発チームへ周知しないまま変更する
Dependabotが突然成功し始めると、今まで作成されなかった更新PRが増えることがあります。セキュリティ更新や依存関係更新のPRが増えるのは良いことですが、レビュー担当者やリリース担当者に周知しないと、未処理PRが溜まる原因になります。
管理者がチームに周知すべき内容
社内周知では、仕組みの詳細よりも「開発者に何が起きるか」を先に伝えると伝わりやすくなります。
そのまま使える文面例は次の通りです。
GitHubのDependabotが、GitHub PackagesおよびContainer registry上のプライベートパッケージを、Personal Access Tokenなしで読み取れるようになりました。
今後、対象パッケージでは「Manage Actions access」にDependabot実行リポジトリをRead権限で追加することで、Dependabotが依存関係を解決できるようになります。
既存のdependabot.ymlにGitHub Packages向けPAT設定があるリポジトリは、管理者側で順次確認し、動作確認後に不要なPAT設定を削除します。外部レジストリ向けの設定は対象外のため、各チームで削除しないでください。
変更後はDependabot PRが増える可能性があります。更新PRのレビュー担当、マージ基準、リリース影響を各チームで確認してください。周知時には、次の3点も併せて伝えると運用が安定します。
| 周知項目 | 開発者に伝える内容 |
|---|---|
| Dependabot PRの増加 | private packageの更新PRが新たに作成される可能性がある |
| PAT削除の扱い | 管理者確認前にDependabot secretsやregistries設定を削除しない |
| 失敗時の連絡先 | パッケージ名、リポジトリ名、Dependabotログを添えて連絡する |
管理者向けチェックリスト
最後に、Automatic Dependabot access to GitHub-hosted registriesの確認事項を実務用チェックリストとして整理します。
| チェック | 確認内容 |
|---|---|
| 対象把握 | GitHub Packages、Container registry、ghcr.ioを使うパッケージを一覧化した |
| Dependabot設定 | dependabot.ymlのregistries設定を確認した |
| PAT棚卸し | GitHub Packages向けPAT、Dependabot secrets、期限なしトークンを洗い出した |
| 権限確認 | 「Manage Actions access」で対象リポジトリにRead権限を付けた |
| 最小権限 | WriteやAdminをDependabot目的で付けていない |
| public repo確認 | publicリポジトリにprivate packageアクセスを付ける場合のリスクを確認した |
| 動作確認 | Dependabotの実行ログでprivate package取得が成功している |
| 移行PR | PAT設定削除はレビュー付きPRで実施した |
| 監査 | 監査ログ、変更申請、パッケージ設定を突き合わせた |
| 周知 | 開発チームにDependabot PR増加と問い合わせ方法を案内した |
| ロールバック | 失敗時に一時的に旧設定へ戻す手順を用意した |
今回の変更で管理者が取るべき行動は明確です。まずGitHub PackagesとDependabotの利用状況を棚卸しし、対象パッケージの「Manage Actions access」でDependabot実行リポジトリにRead権限を付けます。その後、Dependabotの動作確認を行い、GitHubホスト型レジストリ向けに残っているPATベースの設定を段階的に削除します。
重要なのは、PAT削減と権限最小化を同時に進めることです。Dependabotがプライベート依存関係を安全に更新できる状態を作れば、開発チームはセキュリティ更新を取り込みやすくなり、管理者はトークン管理の負担を減らせます。
コメント