GitHub が “Securing the git push pipeline” として、git push 経路に関わる重大なリモートコード実行（RCE）脆弱性への対応をアナウンス しました。これは Git の歴史でも数えるほどしかない、「push 操作そのものから攻撃が成立する」 種類の脆弱性で、CI ランナー・サーバーサイドフック・受託開発で広く使われている自動化基盤に直接的な影響があります。
受託開発の現場は 複数顧客のリポジトリを横断して扱う ため、1 顧客のリポジトリが侵害されると、同じ CI ランナーから他顧客環境へラテラルムーブ が起きやすい構造的弱点があります。本記事では、受託として今回の脆弱性にどう対応すべきかを整理します。
脆弱性の概要 — なぜ受託に重大か
GitHub のアナウンスから、受託視点で重要な点を抽出します。
| 観点 | 内容 |
|---|---|
| 影響範囲 | git push 時のサーバーサイド処理経路にある特定の参照解決ロジック |
| 攻撃成立条件 | 細工されたリファレンスを含む push、またはサーバーサイドフックの設定 |
| 攻撃成立後の挙動 | サーバー側で任意コード実行（RCE） |
| 悪用難度 | 中〜高（ただし PoC が出ると一気に下がる種類） |
| 影響を受ける環境 | GitHub Enterprise Server、自前 Git サーバー、CI ランナー上の Git 操作 |
| GitHub.com（SaaS） | 既に修正済み |
受託で深刻なのは、次の構造です。
- 多顧客 CI 共有：同一 Jenkins / GitHub Actions Runner で複数顧客のリポジトリを処理 → 1 顧客の侵害が全顧客に波及
- オンプレ Git サーバー：顧客環境内の自前 Gitea / GitLab / Bitbucket Server の更新が遅延しがち
- ミラーリング自動化：GitHub → 顧客の社内 Git ミラー、という自動化がトリガーになる
- 古い Git クライアントの常態化：受託先の開発機で 2〜3 年前の Git が動いている
影響評価 — 受託の “棚卸し” チェックリスト
まず受託各社が今すぐやるべきは 影響範囲の棚卸し です。以下のチェックリストを脆弱性アナウンスから 24 時間以内に回します。
[Step 1: クライアント Git クライアント]
├ 開発者全員の `git --version` を収集
├ 修正バージョン未満の開発者を特定
└ 強制アップデートのスケジュール
[Step 2: CI/CD ランナー]
├ GitHub Actions self-hosted runner
├ Jenkins / CircleCI / Buildkite agent
├ Drone / Argo Workflow runner
└ 各イメージの Git バイナリバージョン確認
[Step 3: サーバーサイド Git ホスト]
├ GitHub Enterprise Server
├ GitLab self-managed
├ Gitea / Forgejo
├ Bitbucket Server
└ 自前 Git サーバー（git-shell ベース）
[Step 4: 自動化スクリプト]
├ git push を含むデプロイスクリプト
├ ミラーリング cron
├ 受託案件のデプロイ Bot
└ pre-receive / post-receive フック
[Step 5: 顧客環境]
├ 顧客社内に納品済みの Git ベース基盤
├ 顧客側の運用チームへの周知ルート確認
└ パッチ適用の合意取得Step 5 の顧客環境周知 が受託として最大の責任です。GitHub 上のリポジトリしか見ていない受託会社が多いですが、顧客環境内の Git システムも納品物の延長 として見守る義務があります。
緊急パッチ適用の優先順位
すべてを同時に直すのは現実的でないため、3 段階の優先順位 で動きます。
| 優先度 | 対象 | 期限 | 理由 |
|---|---|---|---|
| P0（即時） | 共有 CI ランナー、本番デプロイ経路 | アナウンス後 24h | 横方向侵害のリスクが最大 |
| P1（72 時間） | 顧客向け Git サーバー、開発者ローカル | アナウンス後 72h | 攻撃 PoC が出る前に塞ぐ |
| P2（1 週間） | 検証環境、社内ツール | アナウンス後 1 週間 | 影響度低だが放置不可 |
P0 の 共有 CI ランナー が最重要です。多くの受託で見られる「1 つの Jenkins で 5 顧客分のジョブを動かす」構成は、1 ジョブからの侵害が他顧客の secret を盗める 構造です。この機会に 顧客別の専用ランナー への分離を検討するのも合理的です。
CI/CD ガードの再設計 — 今後同種の脆弱性に備える
今回の脆弱性は 「push 経路の攻撃」 という新しいクラスに属します。受託として今後備えるべき構造的対策を整理します。
対策 1: ランナーの顧客分離
[Bad Pattern] [Good Pattern]
+------------------+ +------------------+
| Shared CI Runner | | Customer A Runner|
| (5 customers) | | (Customer A only)|
+------------------+ +------------------+
| ./secrets-A | | ./secrets-A |
| ./secrets-B | +------------------+
| ./secrets-C | +------------------+
| ./secrets-D | | Customer B Runner|
| ./secrets-E | | (Customer B only)|
+------------------+ +------------------+GitHub Actions では runs-on: self-hosted のラベルを 顧客別 に切り、ジョブが意図しない顧客のランナーで動かないように ラベルポリシー を組むのが有効です。
対策 2: pre-receive フックの最小化
サーバーサイドフックを増やすほど攻撃面が広がります。受託で組み込みがちな 「commit メッセージ規約チェック」「ファイル名規約チェック」 などのフックは、できるだけクライアント側（pre-commit / Husky）で行う ことで、サーバー側のフック数を減らせます。
対策 3: secret の最小権限化
CI ランナーに置く secret は 「そのジョブが本当に必要なものだけ」 に絞ります。RCE が成立した瞬間、ランナー上のすべての secret が抜かれる前提で設計します。これは HashiCorp Vault 2.0 Identity Federation で扱った “短寿命 secret 配布” の思想と同方向で、static な長期 secret を CI に置かないことが防御の決め手です。
対策 4: SBOM と Git バイナリのインベントリ
CI イメージに含まれる Git バイナリのバージョンを SBOM として継続管理 します。新規の Git CVE が出るたびに、影響を受けるイメージを 5 分以内に特定 できる体制を作っておきます。
対策 5: ミラーリング自動化のサンドボックス化
GitHub → 顧客社内 Git のミラーリング cron は、専用の隔離コンテナ で動かし、ミラー専用の最小権限アカウント で実行します。ミラー経路を通じて顧客環境に侵害が伝播しない構造を組みます。
顧客への通知テンプレート — 受託の “やってます感”
顧客への通知は 「気がついたら直しておきました」 より 「対応しました、影響なしを確認しました」 の方が受託の信頼を生みます。
【ご報告】Git push 経路に関わる重大脆弱性への対応完了について
本日（{日付}）、GitHub から git push パイプラインに関わるリモートコード実行（RCE）脆弱性への対応がアナウンスされました。
貴社環境への影響評価結果：
- GitHub.com 上のリポジトリ：✅ GitHub 側で既に修正済み
- 弊社管理の CI ランナー：✅ {日付 HH:MM} に対応完了
- 開発者ローカル環境：✅ Git バージョンを {x.y.z} 以上に更新済み
- 貴社オンプレミス Git サーバー：⚠️ 貴社運用チームでのパッチ適用が必要 → 別途連絡
今後の予防策：
- 月次の Git クライアント / サーバーバージョン棚卸しを継続
- SBOM ベースで CVE 発令時に影響範囲を 5 分以内に特定する体制
詳細やご質問は弊社担当までお寄せください。
このテンプレートを CVE 発令から 24 時間以内に送付 することが、受託として顧客信頼を守る最大の動きです。
受託としての継続的な備え
このような Git エコシステム規模の脆弱性は 年 1〜2 回は出る 前提で備えるべきです。受託各社が組むべき継続的な備えを整理します。
| 備え | 内容 | 頻度 |
|---|---|---|
| Git バイナリインベントリ | 全 CI / 開発機 / サーバーの Git バージョン台帳 | 月次更新 |
| CVE モニタリング | git-announce, GitHub Security Advisories の自動取得 | 常時 |
| 緊急パッチ訓練 | 模擬 CVE での 24 時間対応訓練 | 半年に 1 回 |
| 顧客連絡フロー | CVE 発令時の顧客通知テンプレ・ルート整備 | 半年に 1 回見直し |
| SBOM 自動生成 | CI イメージビルド時に SBOM を出力・保管 | コミット毎 |
これは GitHub コードセキュリティリスク評価 で扱った “受託のセキュリティ運用標準” と一体で考えるべきテーマで、「CVE が出てから動く」 ではなく 「CVE が出る前提で動く」 体制が利益率を守ります。
まとめ — Git CVE は “受託の試金石”
Git エコシステム規模の脆弱性が出たとき、24 時間以内に顧客全社に対応完了報告ができるか は、受託会社の運用力を測る試金石です。これまで通常運用していた CI 共有や、開発者の Git バージョン放置が、ここで一気に “請求書を立てづらい無償対応” として跳ね返ってきます。
弊社では、Git / Node / Python など主要ランタイムの CVE モニタリング・緊急パッチ適用・顧客通知までをパッケージ化した 受託向けセキュリティ運用契約 を提供しています。「Git CVE が出るたびに社内が混乱する」「顧客への通知ルートが整備されていない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
