GitHubが全リポジトリに所有者を義務付け

GitHubは、社内の主要組織にある1万4000超のリポジトリのうち大半で所有者が不明だった課題を、45日足らずで解消しました。同社はGitHubのカスタムプロパティを使い全アクティブリポジトリに検証済みの所有者を割り当て、使われていない約8000件をアーカイブしたと、2026年7月9日に技術ブログで明らかにしました。背景には、秘密情報の漏洩対応で所有者を特定できず作業が滞る問題がありました。

きっかけは秘密情報スキャンの是正作業でした。漏洩した認証情報を無効化できても、リポジトリの所有者が分からなければ対応は危険で混乱を招き、作業の振り分けもできませんでした。従来はデプロイ済みサービスの所有者だけをService Catalogで管理しており、サービスに紐づかないリポジトリの所有者を探すには、コミット履歴やREADMEを調べSlackで聞いて回る手作業が必要だったのです。

そこで同社は所有者を第一級の属性と位置づけ、組織全体で照会できるカスタムプロパティを採用しました。ownership-typeには「Service Catalog」「Hubber Handle（従業員個人）」「Team」の3種類を用意し、ownership-nameに所有者名を記録します。GitHubアプリが、実在する従業員か、2人以上のメンバーがいるチームか、有効なサービスかを自動検証する仕組みです。

展開にはGitHubアプリとKubernetesのCronJobを使いました。まずService Catalogから約1500件のサービス連動リポジトリへ所有者を自動同期し、残りには所有者設定を促すIssueを起票しました。30日の猶予後も未設定なら、削除ではなく読み取り専用のアーカイブへ移すことで、広範かつ安全に適用できたといいます。

運用では小さな障害も2件起きました。監視ツールDatadogがアーカイブ済みリポジトリにIssueを作れず警告が発生したほか、Service Catalogが古いデータを返せば正当なリポジトリを大量削除する恐れも判明しました。同社は管理者へのメンション通知や、一定数を超える処理を止める安全弁を後から追加して対処しています。

最終的にアクティブは約3000件に絞られ、アーカイブは約3000件から1万1000件へ増えました。2008年の試作品など何年もコミットのないリポジトリが整理され、攻撃対象領域の削減にもつながったとしています。新規作成時の所有者設定も必須化し、検知の猶予も1時間へ短縮して、網羅を維持する構えです。