GitHub Dependabot / code scanning private registries を大規模組織で運用しているなら、2026年4月の更新は「リポジトリごとの脆い設定を減らす」ための重要な変更です。結論から言うと、組織レベルで同じエコシステムに複数のプライベートレジストリを登録できるようになり、npm、Maven、NuGet、Docker、pip などの社内パッケージ基盤を、より一貫した形で Dependabot と code scanning に使わせやすくなりました。GitHub は2026年4月14日のChangelogで、従来はエコシステムごとに1つの組織レベル private registry 設定に限られていたが、今後は同じエコシステムに対して複数の private feeds を登録できると説明しています。(The GitHub Blog)
この変更が効くのは、単に「設定できるレジストリが増えた」からではありません。社内の npm registry、Maven repository、NuGet feed、Docker registry などが部署・製品・地域ごとに分かれている企業でも、Dependabot の更新検知や code scanning の解析に必要なアクセス設定を、組織側で標準化しやすくなる点が本質です。
GitHub Dependabot / code scanning private registries の最新動向
2026年4月15日時点で押さえるべきポイントは、GitHub の organization-level private registries が「単一レジストリ前提」から「複数レジストリ前提」の運用に近づいたことです。
GitHub の発表では、npm、Maven、NuGet、Docker、pip、RubyGems など、対応エコシステム向けに必要な数の private registry を組織の security settings から追加できるとされています。また、OIDC ベースの認証も UI と REST API の両方から設定でき、Azure DevOps Artifacts、AWS CodeArtifact、JFrog Artifactory が対象として挙げられています。提供範囲は github.com と GitHub Enterprise Cloud が先行し、GitHub Enterprise Server では GHES 3.24 から利用可能になる予定です。(The GitHub Blog)
これまでにも Dependabot の private registry 設定は dependabot.yml で可能でした。しかし、リポジトリが数十、数百、数千に増えると、各リポジトリに認証情報やレジストリ設定を散らす運用は破綻しやすくなります。GitHub は2025年7月にも Dependabot の centralized private registry configuration を一般提供し、管理者が組織レベルで private registry access を一元管理できる方向性を示していました。今回の multi-registry support は、その中央集約の実用性をさらに高める更新と見てよいでしょう。(The GitHub Blog)
なぜ大規模組織で multi-registry support が重要なのか
大企業の社内パッケージ管理は、想像以上に単純ではありません。
たとえば、同じ npm でも以下のように複数の参照先が存在することがあります。
| エコシステム | ありがちな社内構成 | 課題 |
|---|---|---|
| npm | GitHub Packages、JFrog Artifactory、製品別スコープの社内registry | チームごとに .npmrc やトークン管理がばらつく |
| Maven | release repository、snapshot repository、レガシー製品用 repository | Javaプロジェクトごとに参照先が異なり、Dependabot が依存関係を解決できない |
| NuGet | Azure DevOps Artifacts の組織feed、部門別feed | PATやfeed URLがリポジトリ単位で複製されやすい |
| Docker | ECR、ACR、Artifactory、社内OCI registry | イメージ取得権限が不足し、解析や更新確認が失敗しやすい |
| Python / pip | 社内PyPIミラー、製品別index | index URLと認証の組み合わせが属人化しやすい |
こうした環境で per-repo setup に頼ると、次の問題が起きます。
- 新規リポジトリを作るたびに、Dependabot 用secretやregistry設定を手作業でコピーする
- 認証情報のローテーション時に、一部リポジトリだけ更新漏れが発生する
- 似た設定ファイルがリポジトリごとに微妙に異なり、障害時の原因調査が難しくなる
- private dependency にアクセスできず、Dependabot が更新PRを作れない
- code scanning が依存関係を十分に解析できず、検出漏れのリスクが残る
GitHub Docs でも、private registry に依存関係がある場合、code scanning default setup や Dependabot などのセキュリティ機能は registry へのアクセスがないと有効性が制限されると説明されています。特に code scanning では、private dependency に含まれる情報へアクセスできないことで、データフロー解析に必要な情報が不足し、脆弱性を検出できないケースがあるとされています。(GitHub Docs)
つまり、multi-registry support は「設定項目の追加」ではなく、社内パッケージセキュリティを組織横断で標準化するための土台です。
従来の per-repo setup と組織レベル設定の違い
大規模組織では、リポジトリごとの自由度を完全になくす必要はありません。重要なのは、共通化すべきものと、リポジトリ側に残すべきものを分けることです。
| 観点 | per-repo setup 中心の運用 | organization-level private registries 中心の運用 |
|---|---|---|
| 認証情報 | 各リポジトリのsecretや dependabot.yml に分散 | 組織の security settings で一元管理 |
| レジストリ追加 | 対象リポジトリごとに設定変更 | 組織側で追加し、対象リポジトリへアクセス範囲を指定 |
| トークン更新 | 更新漏れが起きやすい | 変更箇所を絞りやすい |
| 監査 | どのリポジトリが何を使っているか追いにくい | registry catalog とアクセス方針を作りやすい |
| 例外対応 | すべてが例外設定になりがち | 標準は組織側、特殊事情のみリポジトリ側に残せる |
| 新規リポジトリ | 初期設定漏れが発生しやすい | 標準アクセスを適用しやすい |
実務では、dependabot.yml を完全になくすというより、役割を変えるのが現実的です。認証情報や共通registry URLは組織側へ寄せ、リポジトリ側の dependabot.yml には更新頻度、対象ディレクトリ、グルーピング、除外ルールなど、そのリポジトリ固有の更新ポリシーを残します。
Dependabot では何が改善されるのか
Dependabot は、依存関係のバージョン更新や脆弱性修正PRを作るために、manifest や lock file に書かれた依存関係を解決する必要があります。private registry にあるパッケージへアクセスできなければ、Dependabot はその依存関係を正しく確認できません。
GitHub Docs では、Dependabot は組織レベルの private registries と、リポジトリ内の dependabot.yml で定義された private registries の両方を使用できると説明されています。また、private registry に保存されたコードへアクセスできない場合、Dependabot は security update や version update を確認できず、対象依存関係を更新するPRを作れないとされています。(GitHub Docs)
大規模組織では、この点が非常に重要です。たとえば、ある Java サービスが社内 Maven repository にある共通ライブラリを使っているのに、Dependabot がその Maven repository にアクセスできない場合、脆弱な内部ライブラリが残り続ける可能性があります。逆に、組織レベルで Maven repository 群へのアクセスを標準化しておけば、新規サービスでも更新確認を開始しやすくなります。
Dependabot 側で標準化しやすい項目
| 標準化する項目 | 実務上の効果 |
|---|---|
| registry URL | チームごとの古いURL、ミラー、誤ったfeed参照を減らせる |
| 認証方式 | PAT乱立を抑え、OIDCや管理されたtokenへ寄せやすい |
| repository access policy | 全リポジトリ、private/internalのみ、選択リポジトリなどを明確化できる |
| registry owner | 障害時やローテーション時の問い合わせ先を固定できる |
| 更新対象の優先度 | 重要な社内feedから段階導入できる |
ポイントは「すべてのリポジトリに同じ設定を強制する」ことではありません。共通の土台を組織側に置き、例外だけを小さく管理することです。
code scanning では解析の取りこぼしを減らせる
code scanning private registries の文脈では、private dependency にアクセスできるかどうかが解析品質に影響します。特に CodeQL の default setup を広く展開している組織では、各リポジトリのワークフローを細かく触らずに、組織レベルの registry access を整えられる価値があります。
GitHub Docs では、組織の private registries を定義しておくと、code scanning default setup は解析時に利用可能なregistry定義を使用すると説明されています。初回設定時には、対象リポジトリで code scanning default setup を一度無効化して再有効化する必要があり、その後の新規・変更された設定は以降の実行で自動的に反映されるとされています。(GitHub Docs)
一方で、advanced setup を使っている場合は注意が必要です。GitHub Docs では、code scanning advanced setup は codeql-action を実行するワークフローで利用可能な private registries を使い、default setup 用の organization-level private registries にはアクセスしないと説明されています。つまり、独自の CodeQL workflow を組んでいる組織では、ビルドに必要な registry 認証を workflow 側にも適切に用意する必要があります。(GitHub Docs)
OIDC を使うと長期credential依存を減らせる
private registry の標準化で見落とされがちなのが、認証情報の寿命です。リポジトリごとに長期PATや固定passwordを置く設計は、規模が大きくなるほど管理負荷と漏えいリスクが増えます。
GitHub は、organization-level private registries に対する OIDC 認証サポートも発表しており、OIDC を使うことでクラウドIDプロバイダーから短命credentialを動的に取得できると説明しています。発表時点では、AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactory が対応対象として示されています。(The GitHub Blog)
ただし、OIDC は「有効にすれば終わり」ではありません。クラウド側で GitHub の OIDC provider を信頼する設定、ロールやアプリケーションの権限設計、registryごとの認可範囲が必要です。また、Docs上では organization-level private registries の OIDC について、Dependabot ではサポートされる一方、code scanning default setup では未サポートとする記述もあります。導入時は、対象機能、GitHub Enterprise の提供形態、利用するregistry providerごとに最新Docsを確認してください。(GitHub Docs)
導入前に作るべき registry catalog
multi-registry support を効果的に使うには、いきなり GitHub の設定画面でレジストリを追加するのではなく、先に registry catalog を作るのが安全です。
| 項目 | 記入例 | 確認ポイント |
|---|---|---|
| ecosystem | npm / Maven / NuGet / Docker / pip | Dependabot と code scanning の対象になるか |
| registry URL | https://... | 古いURLやチーム独自ミラーが残っていないか |
| 用途 | 本番ライブラリ、snapshot、社内CLI、base image | 重要度と展開順を決める |
| owner | Platform Team、DevSecOps、製品チーム | 障害時の責任者を明確にする |
| authentication | OIDC、token、username/password | 長期credentialを避けられるか |
| access policy | all、private/internal、selected repositories | 最小権限になっているか |
| 利用チーム | 決済、認証、モバイル、データ基盤 | 不要な組織全体公開を避ける |
| 移行状態 | 未対応、pilot中、移行済み | per-repo設定の削除計画と連動させる |
この台帳がないまま複数レジストリを登録すると、「登録数は増えたが、結局どれが正しいのか分からない」という別の混乱が起きます。特にグローバル企業では、地域ごとに異なる artifact store やネットワーク制約が残っていることがあります。まず現状を棚卸しし、標準registry、例外registry、廃止予定registryを分けることが重要です。
実務での導入手順
現在の per-repo 設定を棚卸しする
最初に、各リポジトリの .github/dependabot.yml、Dependabot secrets、GitHub Actions secrets、package manager設定ファイルを確認します。見るべきポイントは、registry URL、secret名、認証方式、更新対象ディレクトリです。
この段階では、設定の正しさよりも「どれだけばらついているか」を可視化することが目的です。たとえば、同じ Artifactory を参照しているのにURL表記が3種類ある、古いtoken名が残っている、特定チームだけ別のMaven mirrorを使っている、といった差分を洗い出します。
組織レベルへ移す対象を決める
すべてのregistryを一気に移す必要はありません。まずは利用リポジトリ数が多く、セキュリティ影響が大きく、所有者が明確なregistryから始めます。
優先度が高いのは、次のようなregistryです。
- 複数の本番サービスで使われる社内共通ライブラリ
- ベースDockerイメージを配布しているregistry
- 脆弱性対応の遅延が事業影響につながるパッケージfeed
- 新規リポジトリ作成時に必ず設定しているregistry
- credential rotation のたびに作業漏れが起きているregistry
逆に、1つの実験用リポジトリだけが使うregistryや、厳格な分離が必要な外部パートナーfeedは、最初から組織全体の標準にしない方が安全です。
認証方式を選ぶ
認証方式は、長期的な運用負荷で選びます。OIDC が使える環境なら、長期tokenを減らせるため有力な候補です。ただし、クラウド側のtrust設定や権限設計が必要になります。
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| OIDC | AWS CodeArtifact、Azure DevOps Artifacts、JFrog Artifactory などで短命credentialを使いたい | クラウド側の信頼設定と権限設計が必要 |
| Token | 既存registryがtoken認証中心で、早く移行したい | ローテーション手順を必ず決める |
| Username/password | レガシーregistryや特定製品がこの方式しか対応しない | 長期credential化しやすいため、アクセス範囲を絞る |
| self-hosted runner併用 | private network 内のregistryにアクセスする必要がある | runnerのネットワーク、監査、メンテナンスも管理対象になる |
GitHub Docs では、organization-level registries は Token、Username and password、OIDC authentication をサポートすると説明されています。(GitHub Docs)
アクセス範囲を最小権限で設定する
組織レベル設定にすると、つい「全リポジトリから使えるようにする」設計に寄りがちです。しかし、社内パッケージにも機密度があります。
判断基準はシンプルです。
| アクセス範囲 | 使うべき場面 |
|---|---|
| all repositories | 全社標準の共通ライブラリ、全プロジェクト共通のbase image |
| private and internal repositories | 公開リポジトリには不要な社内専用パッケージ |
| selected repositories | 決済、認証、顧客別実装など、利用範囲を明確に絞るべきregistry |
GitHub Docs でも、組織レベルの private registry 設定では、all、private and internal、selected repositories のように、どのリポジトリがそのregistry定義へアクセスできるかを指定できると説明されています。(GitHub Docs)
pilot repository で検証する
いきなり全社展開せず、代表的な3種類のリポジトリで検証します。
| pilot対象 | 検証したいこと |
|---|---|
| 標準的なWebアプリ | Dependabot が通常のversion update / security updateを作れるか |
| private dependency が多いサービス | 複数registryをまたいだ依存解決ができるか |
| code scanning default setup 対象リポジトリ | 解析時に必要なprivate dependencyへアクセスできるか |
検証では、Dependabot のジョブログ、作成されたPR、code scanning の tool status page、Actions log を確認します。GitHub Docs では、code scanning default setup が private registry configuration を利用できたかは tool status page や Actions log で確認できるとされています。(GitHub Docs)
per-repo の認証情報を段階的に削除する
組織レベル設定が動いたら、各リポジトリに残っている重複credentialを削除します。ここを放置すると、古いsecretが残り続け、結局どちらの認証情報が使われているのか分からなくなります。
削除は一括ではなく、次の順で進めると安全です。
| フェーズ | 作業内容 |
|---|---|
| 1 | 組織レベル registry を追加し、selected repositories でpilotに限定 |
| 2 | pilot repository の Dependabot / code scanning 結果を確認 |
| 3 | 対象範囲をチーム単位で拡大 |
| 4 | 重複する repository secret と dependabot.yml 内のregistry認証情報を削除 |
| 5 | registry catalog に移行済みステータスを反映 |
| 6 | 古いtokenを無効化し、失敗するリポジトリがないか監視 |
この順序なら、設定変更とcredential廃止を分けて確認できます。
organization-level と repo-level の使い分け
組織レベル設定が便利になっても、すべてを中央に寄せればよいわけではありません。
| 判断項目 | organization-level が向く | repo-level が向く |
|---|---|---|
| 利用範囲 | 複数チーム・複数リポジトリで使う | 1つのリポジトリだけで使う |
| 管理責任 | Platform / DevSecOps が管理する | 製品チームが個別管理する |
| セキュリティ方針 | 標準化したい | 特殊な例外がある |
| 変更頻度 | 安定している | 実験的で頻繁に変わる |
| 認証方式 | OIDCや共通tokenに寄せたい | 一時的なtokenや特殊な認証が必要 |
| code scanning | default setup を広く使う | advanced setup でworkflow側に組み込む |
おすすめは、「共通registryは organization-level、例外registryは repo-level、更新ポリシーは dependabot.yml」という分担です。これにより、セキュリティチームはアクセス基盤を統制し、開発チームは更新タイミングや対象範囲を柔軟に調整できます。
失敗しやすいポイント
複数登録できることと、無制限に公開してよいことを混同する
multi-registry support は、たくさん登録できる機能です。しかし、すべてのリポジトリにすべてのregistryを開くべきではありません。社内パッケージには、顧客別コード、商用アルゴリズム、未公開SDKなどが含まれることがあります。
アクセス範囲は registry単位で見直し、selected repositories を積極的に使うべきです。
code scanning advanced setup の挙動を見落とす
default setup と advanced setup では、private registry の使い方が異なります。advanced setup で codeql-action を使っている場合、組織レベルの private registry 設定だけでは足りない可能性があります。ビルドworkflow内で package manager がprivate dependencyを取得できるよう、workflow側の認証も確認してください。(GitHub Docs)
OIDC 対応範囲を広く見積もりすぎる
OIDC は有効な選択肢ですが、すべてのregistry、すべてのGitHub構成、すべてのセキュリティ機能で同じように使えるとは限りません。provider、GitHub Enterprise のバージョン、Dependabot と code scanning のどちらで使うのかを分けて確認する必要があります。
古い per-repo secret を残したままにする
移行後に古いsecretを残すと、監査時に「まだ使われているのか」「削除してよいのか」が分からなくなります。移行計画には、secret削除、token失効、失敗時のロールバック手順まで含めてください。
registry URL の正規化をしない
同じregistryでも、URL末尾のスラッシュ、パス、ミラーURL、スコープ付きURLが混在すると、設定の重複や認証ミスが起きます。組織レベルへ移す前に、標準URLを決めておくことが重要です。
DevSecOps チームが次にやるべきこと
今回の更新を活かすには、GitHub の設定画面を開く前に、運用設計を固めることが近道です。
まず、社内の private registry をエコシステム別に棚卸しします。次に、全社標準にすべきregistry、チーム限定にすべきregistry、廃止予定のregistryを分類します。そのうえで、利用頻度が高く、Dependabot や code scanning の効果が大きいregistryから organization-level private registries へ移行します。
特に GitHub Enterprise admins と DevSecOps teams は、以下の3点を優先してください。
- Dependabot が private dependency を解決できないリポジトリを洗い出す
- code scanning default setup の対象リポジトリで、private dependency 由来の解析不足がないか確認する
- 長期tokenを使っているregistryを特定し、OIDCまたは管理されたtoken運用へ移行する
GitHub Dependabot / code scanning private registries の multi-registry support は、大規模組織にとって「設定作業の省力化」だけでなく、「社内パッケージをセキュリティ機能の対象から漏らさないための標準化策」です。リポジトリごとの壊れやすい設定を減らし、組織レベルでregistry access、認証方式、アクセス範囲を管理することで、依存関係更新とコード解析の品質を安定させやすくなります。
コメント