Google CloudのSecure Source Manager強化｜CODEOWNERSと非公開CI/CDをどう使う？

Google Cloud Secure Source Manager CODEOWNERS CI/CD
<style> .sm-hero{padding:clamp(23px,5vw,46px);border-radius:24px;color:#fff;background:linear-gradient(130deg,#172554,#1d4ed8 55%,#0f766e)}.sm-hero h2{color:#fff}.sm-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.sm-card{padding:18px;border:1px solid #bfdbfe;border-radius:16px;background:#eff6ff}.sm-card strong{display:block;font-size:1.55rem;color:#1d4ed8}.sm-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:23px 0}.sm-step{padding:18px;border-radius:14px;background:#ecfeff;border:1px solid #a5f3fc}.sm-step b{display:block;color:#0e7490}.sm-table{overflow-x:auto}.sm-table table{min-width:690px;width:100%;border-collapse:collapse}.sm-table th,.sm-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.sm-table th{background:#dbeafe}.sm-note{padding:18px;border-left:5px solid #f59e0b;border-radius:12px;background:#fffbeb;margin:20px 0}.sm-code{overflow-x:auto;padding:17px;border-radius:12px;background:#0f172a;color:#e2e8f0}@media(max-width:720px){.sm-grid,.sm-flow{grid-template-columns:1fr}} </style>

DEVOPS / GOOGLE CLOUD / 2026年9月21日発表

「誰がマージできるか」と「ビルドがどこへ接続するか」を一緒に設計

Secure Source Manager（SSM）はGoogle Cloudのソースコード管理サービス。今回の発表は、承認ルールとプライベートなCI/CD接続を強化するものです。

2機能Google Cloudが一般提供を発表
ファイル単位CODEOWNERSで承認者を指定
閉域設計SSMとCloud Buildを連携

3行要約

  • Google Cloudは2026年9月21日、SSMのCODEOWNERSと非公開CI/CD連携の一般提供を発表しました。
  • CODEOWNERSはファイル・ブランチ別に承認者を指定し、複数部門の独立した承認も要求できます。ファイルを置くだけでは強制されず、ブランチルールの有効化が必要です。
  • Cloud Build連携ではDeveloper Connectが推奨経路です。ただしGitプロキシのエンドポイントは公開インターネット上に存在するため、完全な閉域要件は代替構成も比較します。

背景：ソース保護は「コード」と「経路」の両方

CI/CD（継続的インテグレーション・継続的デリバリー）は、コード変更からビルド・配布までを自動化します。攻撃者や誤操作がビルド設定を変えると、正しいコードでも危険な成果物が生成され得ます。承認者の絞り込みだけではビルドシステムへの接続経路を守れず、ネットワーク分離だけでは権限を持つ人の誤変更を防げません。

今回の公式ブログは、この二つをそれぞれCODEOWNERSと非公開ネットワーク連携で扱うと説明しています。発表日は2026年9月21日、この記事の確認日は9月23日です。

何が新しいのか

機能できること導入時の注意
CODEOWNERSパスや対象ブランチに応じてPRの承認者を指定。ネストしたファイルと独立承認セクションにも対応ブランチの「Require Code Owner Review」を有効にする。ベースブランチのルールが参照される
Developer Connect連携SSMとCloud Buildを接続。Google Cloudは一般的な推奨経路とするGitプロキシは公開インターネット上。IAMとVPC Service Controlsによる制限を検討
Private Service Connect＋Cloud Build private poolsGitプロキシを公開したくない要件向けの代替経路構成・運用の複雑さを見積もる
1 ソースSSMのリポジトリ
2 承認CODEOWNERSとブランチルール
3 ビルドCloud Buildのプライベートプール
4 成果物アクセスを制限した保存先

これはGoogle Cloudの推奨構成を簡略化した図です。実際の接続はDeveloper ConnectまたはPrivate Service Connectの選択と、IAM・ネットワーク境界の設計に依存します。

CODEOWNERSを試す：ビルド設定への変更に別承認を設ける

SSMのルールは[BRANCH_GLOB] PATH_GLOB [OWNERS...]が基本形です。以下は書式を示す例で、メールアドレスやパスは自社の環境に置き換えてください。

# リポジトリ直下の CODEOWNERS 例
* [email protected]

[Security Team][2]
main /cloudbuild.yaml [email protected] [email protected] [email protected]
main /infra/ [email protected] [email protected] [email protected]

この例では通常のレビュー担当に加え、mainへ入れるビルド設定とインフラ配下の変更に、セキュリティ担当者2人の承認を要求する設計です。担当者を最低2人登録しただけでは2承認にならず、[Security Team][2]の件数指定が必要です。

導入時は次の順に確認します。

  1. 対象リポジトリのベースブランチにCODEOWNERSを置き、オーナーを個人のメールアドレスで指定します。公式ドキュメントではGoogle Groupsは非対応です。
  2. ブランチルールで「Require Code Owner Review on Pull Requests」を有効にします。無効ならCODEOWNERSはマージ要件に使われません。
  3. テストPRでcloudbuild.yamlと通常のソースファイルを別々に変更し、要求承認者が想定通りか確認します。
  4. 次にビルド側の接続経路を設計し、Developer Connectの推奨構成か、Gitプロキシ公開を避けるPrivate Service Connect構成かを選びます。

開発者・企業への影響

単一の「承認者」権限を広く付ける運用から、重要パスの変更だけに専門チームの承認を求める運用へ移しやすくなります。一方、承認者不在はリリース停止につながるため、休暇時の代替者や緊急変更の手順を先に用意すべきです。後者は公式仕様を踏まえた編集上の提案です。

ネットワーク面では、Developer Connect＝全エンドポイントが非公開と誤解しないことが重要です。公式ドキュメントはGitプロキシが公開インターネット上に存在すると明記し、防御を厚くする場合はVPC Service Controlsでアクセスを制限するよう案内しています。公開エンドポイントを許容できない組織には、Private Service ConnectとCloud Build private poolsの代替手順があります。

リスクと限界：提供段階の表記差にも注意

公式情報間の差：9月21日のGoogle Cloudブログは二つの機能を「generally available」と記載しています。一方、9月18日更新のCODEOWNERSドキュメントには「Preview」の表示が残っています。ドキュメント更新が追いついていない可能性はありますが、契約・サポート条件をここで断定せず、導入前に自社の利用リージョンと最新の提供段階をGoogle Cloudへ確認してください。
  • CODEOWNERSは権限管理やブランチ保護の代替ではなく、その上に置く承認要件です。
  • 誤ったパス指定や対象ブランチは、期待したレビューを要求できない原因になります。テストPRで検証します。
  • CI/CDの防御はネットワークだけで完結しません。IAM、ビルド用ID、成果物の権限も合わせて見直します。

今後注目すべき点

CODEOWNERSドキュメントの提供段階表示がブログと整合するか、Developer Connectのプロキシに対する制御手順がどこまで更新されるかを追います。導入する組織は、重要パスの承認漏れとビルド経路の公開範囲を定期点検するのが実務的です。

最終確認日：2026年9月23日

参照元（一次情報）

Previous Post Next Post