シークレットスキャンは 2 種類のスキャナーを併用し、有効性を確かめる：Gitee 725 万リポジトリの調査から
TruffleHog と Kingfisher を同じリポジトリにかけると、共通して見つかったのは約 1,000 件で、片方だけでは全体の約半分しか拾えなかった。1 本のツールで「漏れていない」と判断しない。
調査の内容
- 独立研究者が中国の Git ホスティング Gitee の公開リポジトリ 7,256,531 件を約 1 か月かけて走査し、走査時点で認証できた（有効な）認証情報を 26,400 件見つけた（MongoDB の技術ブログ、Kingfisher チームと協力）。
- 内訳は TruffleHog 12,737 件、Kingfisher 14,664 件、共通 1,001 件。中国の AI サービス Zhipu のキー 1,489 件は TruffleHog に検出器がなく、Kingfisher だけが見つけた。
- 最多は Alibaba Cloud の AccessKey。有効な認証情報の多くは直近 2 年のコミットで、過去のコミットに入ったものも Git 履歴に残り続ける。
実践のコツ
- 2 本以上のスキャナーを並べる: 例えば gitleaks（正規表現中心）と TruffleHog / Kingfisher（検証付き）を CI や定期ジョブで併用し、結果を値で重複排除する。
- 自分が使うサービスの検出器があるか確かめる: 国内・中国・新しい AI サービスのキーは検出器がないことがある。使っているサービスのキー形式がスキャナーの対応表にあるか確認し、なければカスタムルールを足す。
- 「有効かどうか」で優先順位を付ける: 検証機能付きのスキャナーは、事業者の API で実際に認証できるかを確かめられる。有効なものから先に失効させる。
- 履歴まで走査する: 最新のコミットから消しても履歴に残る。
--allなど全履歴を対象にするオプションで走査し、見つかったら失効・交換が先、履歴の書き換えは後。
注意点
- 研究者は漏らした開発者ではなく事業者側へ通知した。漏れた利用者の操作に頼るより、事業者側の失効のほうが確実という立場。自分の鍵が見つかった場合も、まず発行元で失効する。
- 検証付きスキャンは実際に API を呼ぶので、他人の鍵に対して行うと不正アクセスになりうる。走査するのは自分の組織のリポジトリだけにする。