GitHub 大規模オンプレミス組織におけるリポジトリ所有権の再設計と実装

GitHub のプライマリ・オンプレミス組織には 14,000 を超えるリポジトリが配置されています。2025 年初頭時点での状況では、以下の課題が存在していました。

• アーカイブ化されていないリポジトリは約 11,000 にのぼりました。
• その過半数には明確な所有権がありませんでした。
• 本番環境サービスと連携しているリポジトリは確固たる所有権体制を持っていましたが、関連サービスが存在しないリポジトリについては所有者の特定が困難でした。

課題：シークレットスキャンへの影響

この「所有者不明」の状態は、シークレットスキャン対策の実施において重大なリスクとなりました。

• リスク: 技術的に秘密鍵の轮换（rotating）が可能であっても、所有者が不明な状態で実施することは極めて危険であり、業務混乱を招きます。
• 対応困難: アラートに対する意思決定を行う前に、正しい所有者を特定するために多大な時間を要しました。
• 手作業への依存: 所有権のないリポジトリについては、コミット履歴確認、README 読解、Slack での問い合わせなど、非効率な手作業が求められていました。

当初の所有権モデルの問題点

GitHub は従来、「サービスカタログ（Service Catalog）」を通じてサービスの所有権を追跡してきました。

サービスカタログの構造

• メタデータ: サービスからリポジトリへのマッピング、所属チーム、スポンサー情報を記録していました。
• ワークフロー対応: インシデント対応、オンコール振り分け、脆弱性管理に活用されていましたが、以下の根本的な制限がありました。
  • 多対一の関係（Many-to-One）: 1 つのサービスは単一リポジトリのみだが、1 つのリポジトリには複数のサービスが関連付けることが可能でした。
  • 逆引きの不具合: リポジトリから所有者を見つける場合は逆引きが必要でしたが、これはマッピングされているリポジトリに限って機能しました。

その結果生じた「所有権のギャップ」

チーム所有、ドキュメント、内部ツール、一時的プロジェクト、個人的実験、バックアップ用リポジトリなど、サービスに紐付かない約 8,000 のリポジトリが所有者不明の状態でした。これらは定期的なセキュリティワークフローにおいて現実的なリスク要因となっていました。

新しい所有権モデルの設計

リポジトリの所有権を**一次属性（First-Class Property）**として扱うことを決断し、GitHub のカスタムプロパティを採用しました。

採用理由

• ネイティブ構造による照会・管理の容易さ。
• エンタープライズおよび組織ポリシーとの統合可能性。
• リポジトリ作成ワークフローへの強制が可能なため。

実装したカスタムプロパティ

2 つのプロパティを作成し、以下のように定義しました。

1. ownership-type

   : 所有権のカテゴリ（3 値）

   • Service Catalog

     : サービスに属しているリポジトリ

   • Hubber Handle

     : 個人（GitHub エmployee）が所有者

   • Team

     : チームが所有者

2. ownership-name

   : 文字列フィールド
   • 軽微なバリデーションのみ。
   • アプリ側で詳細検証（メンバーシップ確認、組織内存在確認など）。
   • 表記の柔軟性（例:

     @my-team

     や

     my-team

     の両方対応）。

展開プロセスと即日対応

同期機能の開発と適用

サービスカタログからリポジトリへの自動同期機能を構築し、以下の対応を行いました。

• 対象: 既知のサービスに関連する約 1,500 のリポジトリ。
• 処理:

  ownership-type

  を「Service Catalog」に設定し、

  ownership-name

  を自動埋め込み。
• 残存課題: チーム所有、ドキュメント、一時的プロジェクト、個人的なリポジトリへ展開の準備を整えました。

Kubernetes CronJob の導入

GitHub Actions では不十分だったため、Kubernetes CronJob をバックエンドとした GitHub アプリを開発しました。

• アクセス権限: サービスカタログ、GitHub API、内部システムへのアクセスを必要とする強制ロジックを実装。
• スケジュール戦略の失敗と修正:
  • 初回実行を「土曜日の朝」に設定（誰にも気づかないと予想）。
  • 結果: Slack で問い合わせが殺到し、「過ち」と判明しました。組織内には常時オンラインな人がいます。
• 安全な展開方法:
  • 30 日猶予期間: 所有権未設定リポジトリをアーカイブ化（読み取り専用、データは保持）。
  • 可逆性: アンアーカイブして再設定可能なため、リスク低減。
  • ループ間隔の短縮: 安定化後に猶予期間を30 日 → 1 時間に短縮し、即時フラグ付けを実現。

運用上の「鋭利な部分（シャープエッジ）」と改善

展開中に発生した 2 つのインシデントから、以下の教訓を得ました。

インシデント 1: 通知ギャップ

• 原因: 所有権適用なしでアーカイブ化された際、監視ワークフロー（Datadog）がアラートを作成できず、誰も通知されませんでした。
• 改善策:
  • リポジトリ管理者への @mention 導入。
  • 書き込みアクセスユーザー全員のフォールバック割り当て。

インシデント 2: データ信頼性（陳腐化・破損）

• 原因: サービスカタログの障害により、実際には存在するエントリーを「失った」と誤検知し、正当なリポジトリがアーカイブ化されました。
• 改善策: **「低い水位マーク（Low Water Mark）」**の導入。
  • アクション実行前に処理対象数をカウント。
  • 保守的な閾値を超えると実行中止し、Datadog でアラート発火。
  • サービスカタログアクセス不可時は検証をスキップするフォールバックを実装。

成果と定着化

数値結果

• 完了期間: 最初の実行（土曜日）から安定状態まで 45 日以内。
• 最終インベントリ:
  • アクティブリポジトリ: 約 3,000。
  • アーカイブ化リポジトリ: 約 11,000（当初の目標より増加）。
• 効果:
  • 数年间コミットなしの放棄された実験やプロトタイプをアーカイブ化。
  • サプライチェーン攻撃対象領域（Attack Surface）の削減。
  • すべてのアクティブリポジトリに検証済みの所有者が付与。

持続的な維持策

• 強制ルールの適用: リポジトリ作成ページ、内部ツール、自動化において所有権プロパティを必須事項としました。
• 迅速な対応: 所有権を失った場合のフラグ付け期間を30 日 → 1 時間に短縮。
• タイプ別耐久性設計:
  • サービス: デプレシード時はアーカイブ化。
  • チーム: メンバー数が最低 2 名で検証。
  • 個人: 退職時または重要度が低い場合はアーカイブ化（重要ならチーム所有へ）。

あなたの組織への推奨アプローチ

GitHub カスタムプロパティを活用し、以下のステップを参考に実装してください。

• 所有権タクソノミーの定義: サービス、チーム、個人のうち、自組織に最適な分類を選択。
• 組織レベルでのカスタムプロパティ作成:

  • ownership-type

    : 単一選択型（許可値定義）。

  • ownership-name

    : テキスト形式（API 照会可）。
• 既存資産の同期: サービスカタログやインベントリがある場合は、即座に所有権を埋め込みギャップを埋める。
• リポジトリ作成時の強制: 新規作成時にプロパティ必須化し、インベントリの清潔さを維持。
• 猶予期間ワークフローの構築: 無視されたリポジトリは合理的期限（例：30 日）後にアーカイブ化（可逆的であるため安全）。
• 初回実行の日時選定: 土曜日の朝以外に実施する（社内の人間を確認可能にする）。
• ガードレールの構築: データソースの誤りや通知喪失への対策（低い水位マーク、@mention フォールバックなど）を最初から設計に組み込む。

詳細については、GitHub のカスタムプロパティドキュメントをご覧ください。

著者について Michael Recachinas は GitHub の Staff Security Engineer であり、大規模なセキュリティプログラム（脆弱性管理、安全な開発ライフサイクルツール、開発者ファーストのセキュリティ自動化）を担っています。