先に結論
Cloudsmith か Google Artifact Registry を使っているなら、Dependabot の private registry 認証を長寿命 secret のまま放置する理由はかなり減りました。
GitHub は 2026-05-19 に、org-level private registry の OIDC 対応先へ Cloudsmith と Google Artifact Registry を追加しました。
ただし、ここで急いで見たいのは「新しく対応した」ことだけではありません。
- OIDC registry は作成後に認証方式を変えられない
- Cloudsmith と Google Artifact Registry では必須項目が違う
- docs には、OIDC は Dependabot 向けで code scanning default setup は未対応という注記が残っている
つまり今回は、GitHub security を広げるニュースであると同時に、切り替え範囲を雑に広げないための確認記事でもあります。
何が変わったのか
GitHub の changelog では、Dependabot と code scanning の org-level private registry 認証で使える OIDC 対応レジストリに、Cloudsmith と Google Artifact Registry が加わったと案内されています。
これまでの対応先は AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactory でした。
今回の追加で、Cloudsmith や Google Cloud を標準にしている組織も、PAT や長寿命 token を配る運用から短命 credential へ寄せやすくなった わけです。
GitHub の説明はシンプルで、GitHub Actions の OIDC federation に近い発想です。GitHub 側が job ごとに短命 credential を取りに行けるなら、registry 側へ恒久 token を置きっぱなしにする必要が減ります。
まず見直すべきなのは secret ではなく registry 定義
最初に手を付けるべきなのは secret の削除ではありません。
org-level private registry 定義をどう作り直すか です。
GitHub Docs では、organization の private registry に Token、Username and password、OIDC の3種類を選べます。
ただし、認証方式は後から変更できません。
そのため、いま token で作ってある registry を OIDC に寄せたいなら、実務上は「設定を少し直す」より 作り直しに近い作業 になります。
Dependabot を止めずに移すには、次の順で確認しておくのが無難です。
- 今どの registry 定義をどの repository が参照しているか洗い出す
- Cloudsmith か Google Artifact Registry で必要な OIDC trust を先に作る
- org-level private registry を OIDC で新規定義する
- 対象 repository の access scope を最小限で付ける
- Dependabot update job が通ることを見てから古い token ベース定義を外す
この段階を飛ばして secret だけ消すと、更新 PR が止まりやすいです。
Cloudsmith と Google Artifact Registry は入力項目が同じではない
ここは地味ですが、移行時の詰まりどころです。
Cloudsmith の場合
GitHub Docs では、Cloudsmith の OIDC 設定に namespace、service account slug、audience が必要です。
必要なら API host も追加できますが、既定は api.cloudsmith.io です。
つまり Cloudsmith では、どの organization 名前空間に対して、どの service account を GitHub から引き受けさせるかを先に固める必要があります。
Google Artifact Registry の場合
Google Artifact Registry は、Workload Identity Provider の完全なリソース名 と、impersonate する service account のメールアドレス が中心です。
要するに、Google Cloud 側で Workload Identity Pool / Provider を組み、GitHub の OIDC provider を信頼させたうえで、その先に使わせる service account を決める流れになります。
Cloudsmith と比べると、Google Cloud 側の IAM 設計まで含めて見直す場面が多いはずです。
だから「GitHub が対応したからすぐ切り替える」より、どの registry なら今月中に移せるか を分けて考えたほうが実務では進めやすいです。
いちばん大事な注意点は code scanning 側の docs 注記
今回いちばん見落としやすいのはここです。
GitHub changelog では Dependabot と code scanning を並べて案内していますが、GitHub Docs の org-level private registry ページには、OIDC authentication is currently supported by Dependabot. It is not supported by code scanning default setup. という注記が残っています。
この状態だと、少なくとも現時点では Dependabot を先に OIDC 化し、code scanning default setup は別扱いで確認する のが安全です。
code scanning default setup 自体は org-level private registry を使えます。
ただし docs どおりなら、OIDC 前提で同じように置き換えられるとはまだ言い切れません。
ここを雑に読むと、次の事故が起きます。
- Dependabot は通るのに code scanning の解析で private dependency が取れない
- 「OIDC に寄せたから secret を消した」と思ったあとで default setup 側だけ詰まる
- code scanning default setup と advanced setup の違いを混同する
特に code scanning advanced setup は、org-level private registry ではなく workflow 側の credential を使う前提です。
そのため、Dependabot の設計変更と code scanning の設計変更を同じチケットでまとめるより、まず Dependabot、次に code scanning default setup、最後に advanced setup と分けたほうが失敗しにくいです。
GitHub Actions 側の trust boundary まで見直すなら、GitHub Actions security roadmap 2026 で何が変わる？CI/CD セキュリティ選定ガイド もつながります。
今すぐ確認したい運用ポイント
今回の更新で、Cloudsmith や Google Artifact Registry を使う組織が先に見るべきなのは次の4点です。
1. どの repository に org-level registry を開けるか
org-level private registry は、all、private and internal、selected repositories only で公開範囲を決められます。
広く開けるほど楽ですが、least privilege は崩れます。
まず候補になるのは、Dependabot が本当に private dependency を解決する repository だけへ絞る ことです。
2. どの cloud identity と結びつけるか
Cloudsmith なら service account slug、Google Artifact Registry なら service account impersonation が要になります。
ここで監査ログの主体がどこに出るかまで見ておくと、後から調査しやすくなります。
3. 古い token ベース定義をいつ消すか
新しい OIDC 定義が通った瞬間に旧定義を消すのではなく、Dependabot の更新 job が数回安定してから外したほうが安全です。
移行期だけは二重管理に見えても、止血コストよりは安いことが多いです。
4. code scanning を同時に切り替えるか
ここは yes と決め打ちしないほうがいいです。
docs 注記が消えていない以上、code scanning default setup まで同日に寄せるより、まず Dependabot の更新系だけを短命 credential 化して成果を出す ほうが堅いです。
GitHub ネイティブでどこまで security を寄せるかを広く見たいなら、Codex Security vs Snyk vs Semgrep vs GitHub Advanced Security【2026年版】AI時代のAppSecはどれを選ぶべきか も参考になります。
誰から動くべきか
今回すぐ動く価値が高いのは、次のチームです。
- Cloudsmith や Google Artifact Registry に private package を置いている
- repo ごとに token を配る運用が残っている
- Dependabot の update PR を安定させたい
- security review で長寿命 secret の削減を求められている
逆に、private registry をまだ使っていない組織や、code scanning の高度な build 依存まで一気に触りたい組織は、今回の記事だけで結論を急がないほうがいいです。
今回の更新は便利ですが、価値が大きいのは Dependabot の org-level registry 設計を整理できる組織 に寄っています。
今の時点で言えること
Cloudsmith と Google Artifact Registry の追加で、GitHub の org-level private registry OIDC はかなり実戦向きになりました。
一方で、導入判断はまだ単純ではありません。
- Dependabot は OIDC へ寄せる価値が高い
- registry 定義は作り直し前提で考えたほうがいい
- Cloudsmith と Google Artifact Registry では IAM 設計の重さが違う
- code scanning default setup は docs 注記を確認して別レーンで扱うのが安全
結論としては、Cloudsmith / Google Artifact Registry 利用組織は Dependabot から先に OIDC 化を進める のが最も現実的です。
そのうえで、code scanning まで同じ設計で寄せられるかは、GitHub Docs と実環境の両方で確かめてから広げるのがいいと思います。