leak-museum を公開 - git でシークレットを漏らす26の悪例を「博物館」にした教材リポジトリ
当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。
git でうっかりシークレット（API キー・パスワード・秘密鍵などの秘密情報）を漏らしてしまう事故は、いまだに後を絶ちません。そこで、「やってはいけない秘密情報の管理」を26パターン集めて『展示』した教材リポジトリ leak-museum を公開しました。この記事では、何を作ったのか、どう使えるのか、そして設計で工夫した点を紹介します。
WARNING
leak-museum は意図的に安全でないリポジトリで、教育とシークレットスキャナーのテストのために存在します。収録された資格情報はすべて偽物（公式ドキュメントの例示値・本リポジトリ用に使い捨てで生成した値・明らかなプレースホルダ）で、有効だったことは一度もありません。バグバウンティに報告しないでください。実プロジェクトにこれらのパターンを持ち込まないでください。
leak-museum とは
leak-museum は、開発者が git を通じてシークレットを漏らす「古典的な手口」を1か所に集めた、歩いて回れる博物館（museum）です。committed な .env、クラウドキー、SSH/TLS 秘密鍵、データベースダンプ、Kubernetes の Secret マニフェスト、Terraform state、CI ログ、そして「存在を忘れがちな残骸」まで——それぞれを1つの小さな「展示（exhibit）」として、悪い実物ファイル＋なぜ壊滅的か＋正しい対処のセットで並べています。
同時に、シークレットスキャナーのテスト用コーパスとしても機能します。gitleaks や trufflehog、あるいは姉妹ツールの redact をこのリポジトリに向けて走らせ、仕込んだシークレットを何個検出できるかを試せます（答え合わせ用の一覧が PLANTED.md にあります）。
なぜ作ったのか
シークレット漏洩は「起きたら壊滅的、なのに起こしやすい」典型です。公開リポジトリに紛れ込んだクラウドキーは、ボットが常時スキャンしており、露出から数分でクリプトマイナーを立ち上げられたり高額請求につながったりします。国内でもGitHub アカウント経由の不正アクセスが相次いでおり、決して他人事ではありません。
一方で、「どういう置き方が危険か」を実物で並べて見比べられる教材は意外と少ない、というのが作った動機です。ドキュメントで「.env はコミットするな」と言われても、.pgpass・terraform.tfstate・IDE の接続設定・HAR ファイルまで含めて全体像を一望できると、抜け漏れに気づきやすくなります。
26の展示（一部を抜粋）
全26展示は、種類ごとに「なぜ危険か」「正しい対処」がまとまっています。ここでは特に示唆に富むものを抜粋します。
- 01 committed
.env: バージョン管理に絶対入れてはいけない値の塊。.env.productionはさらに危険で、本番系の鍵が漏れます - 08 Kubernetes Secret: 最大の誤解——
data:は base64 エンコードであって暗号化ではありません。echo aHVudGVyMg== | base64 -dで即hunter2に戻ります - 14 消したつもりで履歴に残る:
git rmは最新スナップショットから消すだけで、履歴には残り続けます。git show <commit>:pathの一行で誰でも読めます。これが「直したはずの漏洩」が生き続ける最大の原因です - 15 フロントエンドのバンドル＋ソースマップ: ブラウザに渡すものはブラウザが受け取ります。「minify したから安全」は誤りで、コミットされた
.mapは元の変数名まで復元し、埋め込んだ鍵の「ラベル付き地図」を攻撃者に渡します - 17 弱い JWT 署名鍵:
HS256を短く推測可能な鍵で署名すると、トークン1個から鍵をオフラインで総当たりされ、{"role":"admin"}を偽造されます（JWT の記事も参照） - 25 「エンコード」は「暗号化」ではない: base64 や未署名 JWT ペイロードは鍵なしで復元できます。リポジトリ内の base64 値は平文とみなすべきです
このほか、クラウド資格情報、ハードコード、DB ダンプ＋.pgpass、平文パスワードのメモ、パッケージレジストリのトークン、Terraform state、CI/CD、Dockerfile、モバイルの署名キーストア、.git/config やフックの中、.vscode/JetBrains 設定、.NET appsettings.json、Rails master.key、WordPress wp-config.php、Ansible Vault、クラウド CLI のセッションキャッシュ、HAR/Postman などのデバッグ成果物——と、実務で本当に漏れがちな経路を網羅しています。
「スキャナーは万能ではない」ことを示す設計
このリポジトリで一番伝えたいのは、シークレットスキャナーは安全網ではないという点です。そのために意図的な展示を入れています。
- スキャナーが検出しない展示（17 JWT弱鍵・21 Rails・22 WordPress）: 汎用的な
HS256秘密や DB 資格情報、ソルトは「プロバイダ特有のパターン」ではないため、正規表現ベースのスキャナーは沈黙します。検出ゼロ＝安全、ではないことの一番強い教材です - 履歴だけにある展示（14）: 作業ツリーのスキャン（
--no-git）では見つからず、履歴をスキャンして初めて見つかります。良いスキャナーの分かれ目になります - 意図的に少し壊したプロバイダトークン: printemps-tokyo では GitHub の push protection を組織全体で有効にしているため、GitHub が高確度で検知するトークン（Stripe・Slack・Google・GitHub・Azure など）は接頭辞を残しつつ構造を壊した形で収録しています。正規表現スキャナーはマッチしますが、有効性まで検証するスキャナーは（正しく）無効と扱う——この差自体も学びどころです
正しいやり方も「手本」で示す
悪例だけでは片手落ちなので、同じ構成を正しくやった good-example/ と、逆引きのチェックリスト DO-THIS-INSTEAD.md を同梱しています。要点はこの3つに集約されます。
- git に入れない:
.envなどの危険パスを最初の1コミットから.gitignore。コミットするのは名前と空値だけの.env.example。実行時は環境変数かシークレットマネージャから読む - 正しい保管先を使う: HashiCorp Vault・各クラウドのシークレットマネージャ・SOPS(age/KMS)・Sealed Secrets など。base64 は暗号化ではありません。長期鍵より短命・最小権限・OIDCを優先
- 起きる前に止める: pre-commit フックに gitleaks/trufflehog、ホストの push protection を有効化、CI では作業ツリーと履歴の両方をスキャン
環境変数と .env の扱いは環境変数と .env でのシークレット管理でも詳しく解説しています。
使い方: スキャナーのベンチマークとして
git clone https://github.com/printemps-tokyo/leak-museum
cd leak-museum
# gitleaks の場合（v8.19.0 以降の構文）
gitleaks dir . # 作業ツリーをスキャン
gitleaks git . # 履歴込みでスキャン（展示14が見つかる）補足: gitleaks は v8.19.0 で detect / protect サブコマンドを非推奨にし、git / dir / stdin の3モードに整理しました（README）。旧構文の gitleaks detect --source . --no-git（作業ツリー）と gitleaks detect --source .（履歴込み）も、ヘルプに表示されないだけで引き続き動きます。
検出数を PLANTED.md（答え合わせ）と突き合わせます。良いスキャナーなら、履歴にしか存在しないシークレット（展示14）も検出できるはずです。自作の redact を含め、手元のスキャナーの「取りこぼし」を可視化するのに使ってください。
もし本当に漏らしてしまったら
展示14と16が示すとおり、削除は対処になりません。順序はこうです。
- 今すぐローテーション（再発行）する。push された瞬間に侵害されたと考える。削除ではなくローテーションが本当の対処
- 作業ツリーから除去し、適切な
.gitignoreを追加する - 必要なら
git filter-repo（または BFG）で履歴を書き換え、force-push して全員が clone し直す - pre-commit スキャナーとホストの push protection を入れ、二度と起きないようにする
まとめ
- leak-museum は、git でシークレットを漏らす26のアンチパターンを実物で並べた教材。全て偽の資格情報で、シークレットスキャナーのテストにも使えます
- 「base64 は暗号化ではない」「消しても履歴に残る」「minify は保護ではない」など、誤解しやすい急所を実物で確認できます
- スキャナーは安全網ではない——検出されない展示（JWT弱鍵・Rails・WordPress）を通じてそれを体感できるのが最大の狙いです
good-example/とDO-THIS-INSTEAD.mdで、正しいやり方まで一続きで学べます
ライセンスは MIT です。自分の pre-commit 設定やスキャナーの検証、あるいはチームのセキュリティ勉強会の題材にでも、気軽に使ってみてください。スター・Issue・改善提案も歓迎します。
