GitHub Dependabot / code scanningでprivate package feedsを使っている組織にとって、OIDC対応の最大のメリットは、レジストリ用の長期トークンやパスワードをGitHub Secretsに保存・配布・更新する手間を減らせることです。AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryなどのprivate registriesに対して、必要なときだけ短命の認証情報を取得できるため、漏えいリスク、ローテーション作業、監査対応の負担を下げやすくなります。
2026年4月時点のGitHub更新では、Dependabotとcode scanningがorganization-level private registries向けのOIDC認証に対応したことが発表されました。DevSecOpsチームやGitHub Platform管理者は、「依存関係更新」と「コード解析」の両方で、プライベートパッケージに安全にアクセスさせる設計を見直すタイミングです。(The GitHub Blog)
何が変わったのか：private registriesへのアクセスを組織レベルで扱いやすくなった
今回のポイントは、GitHub Dependabot / code scanningが使うprivate registriesの認証を、リポジトリごとの静的シークレット中心から、組織レベルの設定とOIDC中心に寄せられることです。
GitHubのChangelogでは、Dependabotとcode scanningがorganization-level private registriesに対するOIDC認証をサポートし、長期資格情報をrepository secretsとして保存する必要を減らせると説明されています。対応レジストリとしては、AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryが挙げられており、発表時点ではCloudsmithとGoogle Artifact Registryのサポート追加も予定されています。(The GitHub Blog)
また、別の同日更新では、同じエコシステムに対して複数のprivate registriesを組織レベルで登録できるようになったことも示されています。これにより、npm、Maven、NuGet、Docker、pip、RubyGemsなどで、社内フィードや事業部別フィードを複数持つ組織でも、リポジトリ単位の個別設定に頼りすぎずに管理しやすくなります。(The GitHub Blog)
| 観点 | 従来のよくある運用 | OIDC対応後に狙える運用 |
|---|---|---|
| 認証情報 | PAT、APIトークン、パスワードをGitHub Secretsに保存 | クラウドIDプロバイダーから短命の認証情報を動的に取得 |
| 管理単位 | リポジトリごと、またはDependabot secretsごとに分散 | organization-level private registriesで集約しやすい |
| ローテーション | トークン更新のたびに複数リポジトリへ反映 | 長期シークレットの更新作業を削減 |
| 監査 | 「どこに何の秘密情報があるか」の棚卸しが必要 | 信頼関係、ロール、ポリシー、実行ログを中心に説明しやすい |
| 漏えい時の影響 | 長期トークンが流出すると失効まで影響が続く | 短命トークンのため、影響範囲を抑えやすい |
OIDCが削減する「つらいシークレット管理」とは
private package feedsを使うDependabot運用では、これまで次のような作業が発生しがちでした。
- パッケージレジストリ側で専用ユーザーやトークンを作る
- GitHub側にrepository secretまたはorganization secretとして登録する
dependabot.ymlからそのsecretを参照する- トークンの期限切れや退職者アカウントの整理に合わせて更新する
- どのリポジトリがどのsecretにアクセスできるかを定期的に確認する
- 漏えい時に、影響リポジトリと利用先を急いで洗い出す
小規模なリポジトリなら対応できますが、数十〜数百リポジトリを管理するDevSecOpsチームでは、これが大きな運用負荷になります。特に、社内npmフィード、Mavenリポジトリ、NuGetフィード、コンテナレジストリが混在する組織では、依存関係更新のためだけに多数の長期資格情報を維持することになります。
OIDCでは、この「秘密情報を作ってGitHubに複製する」流れを変えます。GitHubのOIDCモデルでは、GitHub側のジョブがOIDCトークンを取得し、クラウドプロバイダー側がそのトークンのclaimを検証したうえで短命のアクセス資格情報を発行します。GitHub Docsでも、OIDCを使うことで長期のクラウド認証情報をGitHub secretsとして複製せずに済み、より細かい認証・認可管理や自動失効を利用できると説明されています。(GitHub Docs)
仕組みを簡単に言うと：GitHubに「鍵」を置かず、実行時に「通行証」をもらう
OIDCを使ったprivate registriesアクセスは、次のような流れで考えると分かりやすいです。
| ステップ | 何が起きるか | 管理者が見るべきポイント |
|---|---|---|
| クラウド側で信頼関係を作る | AWS IAM、Azure AD、JFrogなどでGitHubのOIDCプロバイダーを信頼する | どのGitHub organization、repository、条件を許可するか |
| GitHub側でprivate registryを登録する | organization settingsまたはAPIでレジストリURL、種類、OIDC関連項目を設定する | 全リポジトリに開けるのか、selected repositoriesに絞るのか |
| Dependabotや解析ジョブが動く | 実行時にGitHubがOIDCトークンを発行する | 実行主体が想定したリポジトリ・条件か |
| クラウド側が検証する | claimがポリシーに合えば短命の認証情報を発行する | ロールや権限が読み取り専用・最小権限になっているか |
重要なのは、OIDCが「認証情報を不要にする魔法」ではないことです。不要になるのは、長期トークンやパスワードをGitHubに保存して使い回す運用です。代わりに、クラウド側の信頼ポリシー、GitHub側のレジストリ定義、リポジトリのアクセス範囲を正しく設計する必要があります。
Dependabotでの実務メリット：private package feedsの更新PRを安全に出しやすくなる
Dependabotは、private registryにアクセスできなければ、そのレジストリにある依存関係のセキュリティ更新やバージョン更新を確認できません。GitHub Docsでも、private registryへのアクセスを設定しない場合、Dependabotはそのレジストリ内の依存関係を更新するpull requestを作成できないと説明されています。(GitHub Docs)
たとえば、次のような組織ではOIDCの価値が大きくなります。
| 利用シーン | 従来の課題 | OIDCで改善しやすい点 |
|---|---|---|
| 社内npmフィードを多数のNode.jsサービスで利用 | npmトークンを各リポジトリに配布しがち | organization-level private registryで集約し、短命資格情報に寄せられる |
| Maven / NuGetの社内ライブラリを複数部門で共有 | 部門ごとに別トークン、別secretが増える | レジストリ単位・リポジトリ範囲単位で管理しやすい |
| AWS CodeArtifactを利用 | AWSアクセスキーの扱いが監査上の論点になりやすい | IAMロールとOIDC信頼ポリシーで制御しやすい |
| JFrog Artifactoryを全社利用 | 長期パスワードやサービスアカウントの棚卸しが重い | OIDC provider名やidentity mappingを使った統制に寄せられる |
DependabotのOIDC認証は、usernameとpassword型の認証を使うレジストリタイプで、AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryにホストされている場合に対応すると説明されています。設定に必要な項目はプロバイダーごとに異なり、AWSではregion、account ID、role名、domainなど、Azure DevOps Artifactsではtenant IDとclient ID、JFrogではOIDC provider nameなどを指定します。(GitHub Docs)
ここでの実務上の狙いは、Dependabotを止めないことです。シークレット管理が面倒だからprivate dependenciesの更新を後回しにする、という状態はサプライチェーンリスクにつながります。OIDCで認証情報の運用負担を下げられれば、Dependabot security updatesやversion updatesを組織全体に展開しやすくなります。
code scanningで重要な理由：private dependenciesを読めない解析は見落としにつながる
code scanningでもprivate registriesへのアクセスは重要です。GitHub Docsでは、リポジトリのコードがprivate registry内の依存関係を使っている場合、code scanning default setupやDependabotなどのセキュリティ機能は、その依存関係へアクセスできないと効果が制限されると説明されています。特にcode scanningでは、アクセスできない依存関係があるとデータフローの一部を解釈できず、脆弱性を検出できないfalse negativeにつながる可能性があります。(GitHub Docs)
これは、単に「ビルドが通るか」だけの問題ではありません。たとえば、社内ライブラリに入力検証、認可チェック、SQL実行、HTTPクライアント、シリアライズ処理などが含まれている場合、code scanningがその中身や型情報を十分に見られないと、アプリケーション全体のデータの流れを正確に追いにくくなります。
ただし、code scanningは設定方式によって見るべきポイントが変わります。GitHub Docsでは、code scanning default setupはorganization-level private registriesの定義を利用できる一方、advanced setupではcodeql-actionを実行するワークフローが利用できるprivate registriesが対象であり、default setup用のorganization-level private registriesにはアクセスしないと説明されています。(GitHub Docs)
そのため、GitHub Platform管理者は次のように切り分けると安全です。
| 利用形態 | 確認すべきこと |
|---|---|
| code scanning default setup | organization-level private registryの定義が対象リポジトリに許可されているか |
| code scanning advanced setup | CodeQLを実行するActions workflow内で、ビルドに必要なprivate registriesへアクセスできるか |
| Dependabot updates | Dependabotが対象private registryを使えるか、更新ジョブのログで失敗していないか |
ロールアウト直後の機能は、UI、REST API、ドキュメントの表記が変わることがあります。特にOIDCをcode scanningで使う場合は、自社のGitHubプラン、GitHub Enterprise Serverのバージョン、default setup / advanced setupのどちらかを確認し、小さなリポジトリで動作検証してから全社展開するのが現実的です。
導入すべき組織の判断基準
OIDC対応は、すべての組織が即日移行すべき機能ではありません。ただし、次の条件に当てはまる場合は優先度が高いです。
| 状況 | 優先度 | 理由 |
|---|---|---|
| private package feedsを複数のリポジトリで使っている | 高 | secretの配布・棚卸し・ローテーション負荷が大きい |
| AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryを使っている | 高 | OIDC対応の対象になりやすい |
| Dependabotの更新PRがprivate dependenciesで失敗している | 高 | 認証方式を整理すると更新自動化を再開しやすい |
| code scanningの解析精度を組織全体で上げたい | 中〜高 | private dependenciesにアクセスできない解析の見落としを減らせる |
| リポジトリ数が少なく、既存secretの管理が単純 | 中 | 急がなくてもよいが、将来の標準方式として検討価値がある |
| 独自レジストリや未対応プロバイダー中心 | 低〜中 | 対応状況を確認し、従来方式と併用する必要がある |
判断の軸は、「OIDCが使えるか」だけではなく、「今の長期シークレット運用がどれだけリスクと手間を生んでいるか」です。監査で毎回secret一覧を説明している、退職者やサービスアカウントの棚卸しが重い、トークン期限切れでDependabotが止まりがち、といった組織ほど効果が出やすくなります。
移行手順：いきなり全社展開せず、1フィード・数リポジトリから始める
OIDC移行は、GitHub側だけで完結しません。クラウドID、パッケージレジストリ、GitHub organization設定、対象リポジトリの運用を合わせて設計します。
| 手順 | 作業内容 | 失敗しないための確認点 |
|---|---|---|
| 依存関係とフィードを棚卸しする | npm、Maven、NuGet、pipなど、どのリポジトリがどのprivate registryを使うか整理する | 「誰も管理していない古いsecret」がないかも確認する |
| 対象プロバイダーを選ぶ | AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryなど、OIDC対応対象を優先する | 未対応レジストリは従来方式を残す |
| クラウド側で信頼関係を作る | AWS IAM OIDC provider、Azure federated credential、JFrog OIDC providerなどを設定する | organization、repository、audience、role条件を広げすぎない |
| GitHub organizationにprivate registryを登録する | SettingsのSecurity配下、またはREST APIでregistry定義を作る | all repositoriesではなく、まずselected repositoriesで始める |
| Pilotリポジトリで検証する | Dependabot update job、code scanningの解析、Actionsログを確認する | 失敗ログを残し、権限不足かURLミスかを切り分ける |
| 既存secretを段階的に廃止する | 使われなくなったPAT、パスワード、サービスアカウントを削除・失効する | 削除前に参照元検索とロールバック手順を用意する |
| 標準テンプレート化する | 新規リポジトリ作成時のDependabot設定、registryアクセス申請、レビュー観点を文書化する | 例外申請のルールも決めておく |
code scanning default setupで初めてprivate registry設定を使う場合、GitHub Docsでは、対象リポジトリでcode scanning default setupをいったん無効化して再有効化する必要があると説明されています。また、private registriesが解析に使われたかはtool status pageやActionsログで確認できます。(GitHub Docs)
OIDC移行で失敗しやすいポイント
信頼ポリシーを広げすぎる
OIDCでは、GitHubに長期シークレットを置かない代わりに、クラウド側の信頼ポリシーが重要になります。
たとえば、organization全体を無条件で許可すると、本来アクセスさせたくないリポジトリからも同じレジストリに到達できる可能性があります。最初は対象リポジトリ、ブランチ、環境、repository visibility、custom propertyなどで絞り、必要に応じて広げる設計が安全です。
「OIDCにしたからローテーション不要」と考える
短命トークンは自動で期限切れになりますが、信頼関係そのもののレビューは必要です。クラウド側のロール、Azure ADアプリ、JFrogのidentity mapping、GitHub側のprivate registry定義は、定期的に棚卸しするべきです。
見直すべき観点は次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| 対象リポジトリ | すでに廃止されたリポジトリが許可されていないか |
| 権限 | 読み取りだけで足りるのに書き込み権限が付いていないか |
| audience | 意図したGitHub organizationやプロバイダー向けに限定されているか |
| ロール名・client ID | 使途が分かる命名になっているか |
| ログ | 誰が、どのジョブで、どのレジストリへアクセスしたか追えるか |
authentication typeを後から変えられる前提で作る
GitHub Docsでは、private registry作成後にauthentication typeは変更できず、OIDCから別方式へ、または別方式からOIDCへ切り替えるには既存registryを削除して作り直す必要があると説明されています。(GitHub Docs)
そのため、本番登録前にPilot用のregistry定義で検証し、命名、URL、provider-specific fields、対象リポジトリ範囲を確認してから展開する方が安全です。
Dependabotの外部コード実行制限を見落とす
Dependabotにprivate registryへのアクセスを与えると、GitHubは保護のため外部コード実行を自動的に無効化します。その結果、一部のversion updatesが失敗する場合があります。必要な場合はinsecure-external-code-executionの扱いを検討できますが、これはリスクを理解したうえで、対象を絞って使うべき設定です。(GitHub Docs)
code scanning advanced setupとdefault setupを混同する
code scanning advanced setupでは、CodeQLを実行するActions workflowがビルドを観測します。そのため、ビルド時にprivate registryへアクセスできるよう、workflow側の認証設計が必要です。organization-level private registriesを登録しただけでadvanced setupのビルドが自動的に解決する、とは考えない方が安全です。(GitHub Docs)
セキュリティとコンプライアンスでの価値
OIDC plus private registriesが重要なのは、単にDependabotの設定が楽になるからではありません。ソフトウェアサプライチェーンの統制ポイントを、散らばったsecretから、IDプロバイダーとポリシーに移せる点に価値があります。
特にグローバル組織では、次のような説明がしやすくなります。
| 監査・統制の観点 | OIDCで説明しやすくなること |
|---|---|
| 最小権限 | どのrepositoryが、どのroleで、どのregistryを読めるかをポリシーで制御できる |
| 資格情報の寿命 | 長期secretではなく、ジョブ単位の短命credentialを使う |
| アクセスの一貫性 | リポジトリごとの手作業ではなく、organization-level設定に集約できる |
| 退職・異動対応 | 個人PATに依存したregistryアクセスを減らせる |
| インシデント対応 | 漏えいしたsecret探しではなく、信頼ポリシーとロールを中心に遮断できる |
ただし、OIDCに移行しても、すべての運用リスクが消えるわけではありません。広すぎるロール、雑なrepository access設定、検証されていないregistry URL、ログ未確認のままの全社展開は、別の形のリスクになります。
まず取るべき次の行動
最初にやるべきことは、OIDC対応の有無を調べることではなく、現在のprivate package feedsとシークレットの棚卸しです。
次の順番で進めると、失敗しにくくなります。
- Dependabotやcode scanningで失敗しているprivate dependenciesを洗い出す
- GitHub organization内のDependabot secrets、repository secrets、private registries設定を確認する
- AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactoryのどれを優先移行するか決める
- selected repositoriesでPilotを作り、Dependabot jobとcode scanningログを確認する
- 成功した設定をテンプレート化し、古い長期secretを段階的に削除する
OIDC対応の本質は、「便利な新認証方式を追加すること」ではありません。Dependabotとcode scanningがprivate registriesへ安全にアクセスできる状態を作り、長期シークレットの配布・更新・監査というつらい作業を減らすことです。private package feedsを多用している組織ほど、まずは1つの重要フィードからOIDC化を検証する価値があります。
コメント