中国最大のGitプラットフォームGiteeの725万リポジトリスキャンで26,400件のライブ認証情報発見

中国最大のGitプラットフォームGiteeの725万公開リポジトリスキャンで認証情報（シークレット）を発見

このゲスト投稿は、独立系セキュリティ研究者Ben Zimmermann氏によるもので、MongoDBのKingfisherチームと協力して作成されました。Ben氏は、公開ソースホスティングプラットフォームにおける大規模な認証情報漏洩の研究を専門としています。

要約: Gitee（中国最大の国産Gitホスティングプラットフォーム）の7,256,531件の公開リポジトリをTruffleHogとKingfisherを使用してスキャンした結果、26,400件のユニークで検証済みのライブ認証情報を発見しました。これには、主要なエンタープライズAIプラットフォームの有効な組織管理者認証情報や、数千件のライブクラウドプロバイダーアクセスキーが含まれていました。

Giteeとは？

OSChinaによって2013年にローンチされたGiteeは、中国工業情報化部によって国のオープンソースコードホスティングプラットフォームとして選定されました。その公開APIは、GitHubやGitLabと比較して著しく制限されています。ページネーションされたプロジェクトエンドポイントがなく、サイト上のコード検索機能は数年前に廃止されたようです。2021年の試みでは、Giteeでの認証情報漏洩を調査しましたが、APIが研究をスケールするには限定的すぎると結論付けられました。

他の大規模Gitプラットフォームと同様に、認証情報漏洩の魅力的な表面となっています：

• Gitベースであるため、コミット履歴の奥深くに埋め込まれたシークレットは永続します。
• アクティブなコミットボリュームを持つ数百万の公開リポジトリをホストしています。
• GitHubで標準となっているプラットフォームベンダーとのシークレットスキャンパートナーシップに相当する公開サービスがありません。

数百万のGiteeリポジトリの列挙

Giteeの公開APIは著しく制限されているため、数百万のリポジトリを列挙するには多くの表面を組み合わせる必要がありました。大規模な有用なデータを返した唯一の公式RESTエンドポイント、プラットフォームのExploreフィード、ウェブサイト自体のユーザーごとのリポジトリおよびスター付きプロジェクトページ、そしてサイト内検索UIのバックエンドとなっているGiteeの内部Elasticsearchウィジェットです。

ユーザー名コーパスのブートストラップ

大規模な有用なデータを返した単一の公式RESTエンドポイントは、GET /api/v5/search/users?q=.でした。私はこれを3文字のプレフィックスクエリ（aaa、aab、...、zzz）で実行し、結果を公開Exploreフィード（/explore/all?order=starred|popular|updated）から抽出したユーザー名と組み合わせました。その後、各ユーザーのフォローリストと人気リポジトリのスター付けリストを通じてそのセットを拡張しました。これにより、1,704,759件のユーザー名のシードコーパスが生成されました。

フロントエンドでのユーザーページスクレイピング

ユーザー名コーパスが手に入った後、2つのユーザーページからリポジトリを取得しました：gitee.com/{user}/projects（ユーザー自身のリポジトリ）とgitee.com/{user}/stared_projects（ユーザーがスターを付けたリポジトリ）。/projectsのページ1は完全なHTMLを返しますが、それ以降のページはAJAXでページネーションされます（X-Requested-With: XMLHttpRequest）。ユーザー名ブートストラップ中に使用されたスター付けリストページも同様にページネーションされ、さらにページ1のHTMLから抽出されたCSRFトークンが必要でした。

サイト内検索ウィジェットのクエリ

プラットフォームの大部分はソーシャルグラフの外にあります。それにアクセスするために、私はGiteeのサイト内検索UIのバックエンドとなっているのと同じ内部Elasticsearchエンドポイントを使用しました：so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya。これは、クエリID、qパラメータ、およびfrom + sizeによるページネーションを取ります：

Unformatted
Code Snippet

各クエリはページあたり最大20件の結果を返しましたが、実際に一致した件数に関わらず、合計で200件の結果というハードキャップがありました（from + size <= MAX_RESULTS）。特定のユーザー名の場合はこれで十分でしたが、一般的なユーザー名やウィジェットに対するトライグラムプレフィックスクエリでは、キャップによって結果がサイレントに切り捨てられました。

バケット分割による200件の結果キャップからの脱出

ウィジェットの応答には、言語（编程语言）とライセンス（许可证）で結果をバケット化するElasticsearch集計が含まれています。ユーザー名ごとのスクレイピングでは、クエリがキャップされた場合、応答が既に返した言語バケットで分割しました：

Unformatted
Code Snippet

ウィジェットに対するトライグラムプレフィックスクエリ（私が発見したどのユーザーとも関連付けられていないリポジトリを表面化するために使用）では、これをクエリツリー上のBFSに拡張しました。キャップされたノードは、まず言語で分割され、次にライセンスで分割され、次に各ブランチが200件の結果に収まるまでさらに深いプレフィックスで分割されました。

すべてのソースからリポジトリIDを重複排除した後、7,256,531件のユニークな公開Giteeリポジトリのワーキングセットが生成されました。

スキャンパイプラインの配線

次の課題は、725万リポジトリのクローンを作成し、スキャンすることでした。これを単一のPythonスクリプトで実行するために、AIワークロードで人気のあるサーバーレスコンピューティングプラットフォームであるModalを使用しましたが、ほとんどの並列ジョブに適しています。カバレッジを向上させるために、TruffleHogとKingfisherをすべてのリポジトリに対して同時に実行しました。各表面は、もう一方が見逃した認証情報を検証したため、両方を実行することで、どちらか一方よりも多くの露出した認証情報をキャッチしました。

図1. デュアルスキャナーパイプラインアーキテクチャ。

Dockerイメージ

コンテナイメージはマルチステージビルドで、両方のスキャナーバイナリをアップストリームリリースから単一のPythonベースにプルし、さらにgitとOpenSSHをクローン用に含んでいます：

Unformatted
Code Snippet

リポジトリごとのスキャン関数

単一のModal関数は、各リポジトリをSSH経由でベアクローンし、同じディスク上のクローンに対して両方のスキャナーをサブプロセスとして同時に実行します：

Unformatted
Code Snippet

725万リポジトリのバッチ処理

コーパスを約15万リポジトリの50バッチに分割し、それらを毎分350コンテナの一定レートで連続して実行しました。この規模では、より小さなバッチの方が安全で、中断後の再開が容易でした。より大きなバッチの実行は不安定で、クローン側のブロックにヒットしました。

コストと規模

総壁時間：約1ヶ月の連続実行。リポジトリごとのクローン時間は主要な要因でした：Giteeのサーバーは中国にあり、太平洋を横断するネットワーク距離とSSHプロトコルのオーバーヘッドにより、各クローンは同等のGitHubクローンよりも実質的に遅くなりました。総コストは3,097.64ドルで、この研究を支援したModalからの5,000ドルのコンピューティングクレジットスポンサーシップによって全額吸収されました。この同じModal + デュアルスキャナーアーキテクチャは、クローンURLの置換以外はほとんど必要なく、ほとんどのGitホストで機能します。私は、Algolia DocSearch管理キーの以前の調査でこのアプローチの小規模バージョンを使用しました。

結果

スキャンされた7,256,531件の公開Giteeリポジトリ全体で、デュアルスキャナーパイプラインは、トークン値による重複排除後、26,400件のユニークで検証済みのライブ認証情報を表面化しました。

どちらのスキャナーも、スキャン時にベンダーのAPIに対して各候補を認証します（TruffleHogの--only-verifiedとKingfisherの--only-validモード）。パターンマッチングはするが認証に失敗したものはすべて破棄されます。26,400件という数字は、生のシークレット値で重複排除されているため、リポジトリ間またはスキャナー間の重複は1回としてカウントされます。

どちらか一方のスキャナーだけでは、これらの認証情報の約半分しか検出できませんでした。2つのツールの検出器のカバレッジは大部分が補完的でした：TruffleHogはAlibaba Cloudキー検出（9,428件対993件）を支配しましたが、KingfisherはDeepSeek（2,940件対230件）、OpenAI（1,198件対150件）、HuggingFace（154件対1件）、およびTruffleHogには検出器がないZhipuのような中国AIサービス（1,489件対0件）を支配しました。

タイプ別のシークレット

最も一般的な漏洩認証情報のタイプはAlibaba CloudのAccessKeyペアでした：Giteeリポジトリ766件あたり約1件に、有効なAlibaba Cloud認証情報が含まれていました。

図2. ベンダー別の認証情報。

その他のベンダー（LangSmith、OpenWeather、Algolia、PostHog、OpenRouter、MySQL、Stripe、Twitterなど）のロングテールが残りを占めています。

コミット日別のシークレット

検証済みのライブ認証情報の大部分は、過去2年間にコミットされたものでした。2025年だけで12,242件のユニークな認証情報があり、データセット全体のほぼ半分を占めています。

図3. 年別のユニークな認証情報コミット。

コミッターのメールドメイン別のシークレット

ほとんどの認証情報は、個人のメールサービス（qq.com、163.com、gmail.com）からコミットされており、企業ごとの帰属を大規模に行うことは不可能でした。以下の企業ドメインの数値は最低限のものであり、それでも名前は主要な中国および西洋のテクノロジー企業の両方にまたがっています。

図5. コミッターのメールドメイン別のユニークな認証情報。

Oracle、Apple、Meta、Anthropicなどからの小規模な企業フットプリントも出現しており、さらに中国の商用および学術ドメインも含まれています。

GiteeとGitLab、Bitbucketとの比較

最も近い過去のデータポイントは、TruffleSecurityによる560万件の公開GitLabリポジトリのスキャンと、その投稿で参照されている付随するBitbucketスキャンからのものです。

Giteeは、生のカウントとリポジトリあたりの密度において、両方の西洋プラットフォームを上回っています。方法論に関する注記：TruffleSecurityのスキャンではTruffleHogのみを使用しましたが、今回のスキャンではTruffleHogとKingfisherを組み合わせて使用しました。TruffleHogの検出器ライブラリは西洋のベンダーに偏っており、GiteeにはKingfisherのカバレッジが表面化を助ける多くの中国ベンダー（Alibaba Cloud、DeepSeek、Zhipuなど）のアクティビティがあります。当社の結果をTruffleHogのみに絞ると、Giteeは1,000リポジトリあたり1.76件になります。

開示

このスキャンで最も高い露出量を示したベンダーに電子メールを送り、各ベンダーに、サービスに関連する検証済みのライブ認証情報の完全なリストと、影響を受けた顧客を帰属させるのに役立つソースリポジトリメタデータを含む、調整されたレポートを提供しました。

開発者ごとの通知（漏洩した各認証情報のコミッターに個別に連絡すること）は、この規模では追求されませんでした。ベンダー側の取り消しは、漏洩した認証情報をユーザーがアクションを取る必要がないため、より信頼性の高いパスです。

執筆時点では、開示された認証情報の取り消しステータスはまだ確認されていません。

まとめ

• Giteeは意味のある認証情報漏洩の表面です。 725万リポジトリにわたる26,400件の検証済みのライブ認証情報。リポジトリあたりの密度は、GitLabとBitbucketの比較可能な公開スキャンよりも高いです。

• 大手テクノロジー企業がコミッターメタデータに登場します。中国と西洋の両方です。 その範囲には、Huawei、ByteDance、Google、Microsoft、Oracleなどが含まれており、これが純粋に中国の開発者だけの現象ではないことを示唆しています。

• 開示パスは非対称です。 西洋企業は通常、バグバウンティプログラムまたはアクセス可能なセキュリティチャネルを持っています。ほとんどの中国企業はそうではないため、漏洩した認証情報には明確な修復パスがありません。

• アーキテクチャはポータブルです。 同じModal + デュアルスキャナーパイプラインは、クローンURLの置換以外はほとんど必要なく、ほとんどのGitホストで機能します。完全なスキャンのコストは約3,000ドルでした。