2026.05.25

【GitHub・コードリポジトリ偵察編】コミットに眠るシークレットを掘る｜CTF思考フレームワーク R07

安全に生きたい編集部

GitHub の偵察って、公開リポジトリから何取るの？コードしかなくない？📦

実はコミット履歴に『削除されたパスワード・APIキー』が残っています。git log で過去のコミットを遡れば、開発者が一度コミットしてから削除した秘密情報が丸ごと取得できます。Bug Bounty の上位を独占する偵察手法です。

GitHub・コードリポジトリの偵察は、Bug Bounty で最も高評価されるテクニック。組織所属開発者の個人 GitHub アカウント、コミット履歴の秘密情報、社員が誤って公開した社内ライブラリ。trufflehog・gitleaks・github-search で、過去の漏洩情報が次々見つかります。

広告・PRを含みます。この記事にはアフィリエイトリンクが含まれます。掲載内容は編集方針に基づいて作成していますが、価格・在庫・キャンペーン内容はリンク先で最新情報を確認してください。

GitHub のコミット履歴って、削除しても残るんだ…

この記事は、CTF思考フレームワーク Recon編 R07。GitHub・コードリポジトリ偵察の手法（trufflehog・gitleaks・GitHub search）と、過去の漏洩シークレット事例、自社の漏洩点検（GitHub Secret Scanning）を整理します。

GitHubは攻撃者にとって「公開シークレットの宝庫」。社員が個人開発のついでにコミットしてしまったAPIキー、過去に削除したつもりがhistoryに残ったDBパスワード、forkされた別リポジトリに残った.env…毎週どこかで漏洩事故が起きています🐙

コードを公開する文化と引き換えに、シークレットの漏洩リスクは劇的に高まりました。

この記事で出てくる言葉

先に意味を押さえておくと読みやすい用語です。

CTF: セキュリティの練習問題を解く競技。必ず許可された環境だけで試します。

この記事の難易度

難易度：★★☆（中級） ／この枝ルートの記事は、必要な回だけ選んで読めます。

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🧪 自分で検証ラボを作る
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
✍️ 学んだことを発信する
⚖️ 大事なお約束

👀 観察フェーズ：まず何を見る？

リポジトリの「現在の中身」だけ見るのは初心者。本当の宝は「過去」と「削除済みブランチ」と「forkされた別アカウント」にあります。

🤔 仮説フェーズ：攻撃者は何を考える？

攻撃者は「組織が公式に出している OSS リポジトリ」よりも、「社員個人のアカウントから漏れている業務コード」を狙います。GitHub の検索で『”company.com” extension:env』『”@company.com” filename:.npmrc』『”company-internal” path:.aws/credentials』のように、企業ドメインや内部プロジェクト名をキーにしたコードサーチを走らせ、社員が個人 PC のバックアップ感覚で push してしまったファイルを掘り当てます。さらに GitHub の Events API や GH Archive を遡れば、削除済みリポジトリの初期コミットすら再現できるため、消したから安全という前提は通用しません。

攻撃者にとってGitHubは「組織が無意識に発信する内部情報の塊」です。

🔬 検証フェーズ：どうやって確かめる？

手順は三段です。まず GitHub の Web 検索と gh CLI で、対象組織の公式 org と所属メンバーの個人 org を全部洗い出します。次に各リポジトリを ghorg などで一括 clone し、trufflehog や gitleaks を『–since-commit』なしで全履歴に対して走らせ、AWS キー、Slack トークン、JWT 秘密鍵、private_key BEGIN ブロックを拾います。最後に、漏れていたシークレットの prefix や末尾 4 文字を頼りに、有効なまま放置されていないかをサンドボックス側で軽く確認する、という流れです。なお業務で行うときは、必ず正規の Bug Bounty スコープか書面の許可がある範囲だけにとどめます。

⚔️ 攻撃フェーズ：実際の手口

象徴的なシナリオは、GitHub Actions のログ漏洩です。開発者が『echo $AWS_SECRET_ACCESS_KEY』をデバッグ用に書き、public リポジトリの Actions ログにそのまま出力されてしまう。攻撃者はリポジトリの Actions タブから過去のラン履歴を遡り、マスキング前のキーを拾い上げます。もう一つよくあるのが、private から public への切替事故です。社内 PoC として作ったリポジトリを「成果物の公開デモ」として public にした瞬間、過去 2 年分のコミットに残っていた本番 DB パスワードが全世界に公開される、という事故が定期的に発生しています。

CTF{git_history_never_forgets_a_secret}

結論：「git push したシークレットは、削除しても残る」。即時ローテと監視の組み合わせが必須です。

🛡️ 防御フェーズ：どう守る？

守る側の起点は GitHub Advanced Security の Push Protection と Secret Scanning を org 全体で強制適用することです。これで push 段階で 80% 以上の主要シークレットは止まります。残り 20% への備えとして、pre-commit に gitleaks、CI で trufflehog の差分スキャン、そして社員個人アカウントが業務コードを置いていないか四半期ごとに棚卸しする運用を組みます。万が一漏れた場合の SLA も重要で、検知から 15 分以内にキーを失効・ローテし、影響範囲のログを CloudTrail / Audit Log で確認する、というプレイブックを事前に書いておくと事故が事件に発展するのを防げます。

🧪 自分で検証ラボを作る

Reconコマンドを安全に試すには、自分専用の検証ラボが一番。🏗️ ConoHa VPSなら月額数百円からLinux環境を立てられ、nmapやgobusterなどのツールを「自分のサーバ」に打ち込んで安全に試せます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

現場でしばしば見る落とし穴は、git rm 後に commit して「消したので OK」と判断してしまうパターンです。実際にはコミットオブジェクトに残るため、git log -p や trufflehog で容易に復元されます。さらに、fork された別アカウントの古いコピーを忘れて本家だけ rotate しても、fork 側に同じシークレットが生き続けている、というのも頻発します。Push Protection を org 全体ではなく一部リポジトリにしか掛けていない、Actions の secrets を echo で吐いてしまう、といった「設定一つで防げたのに」というケースが事故報告の多くを占めます。

「削除したから大丈夫」と思い込む（git logには残る）。
GitHub Push Protectionを無効にしている、もしくは個人レポに適用していない。
社員の個人GitHubが業務コードで埋まっている状態を放置。
GitHub Actionsで secrets を echo / cat / env でうっかり出力。
Forkされた古いバージョンの存在を忘れ、本家だけ修正して放置。
プライベートからパブリックに切り替えた瞬間に履歴が露出することを意識していない。

🧰 ツール早見表

GitHub 偵察と漏洩対策の道具立ては、攻撃と防御で対になっています。攻撃側は trufflehog で履歴全体のエントロピー検出、gitleaks で差分ベースのパターン検出、GH Archive と BigQuery で削除済みイベントの掘り返し。防御側は GitHub Advanced Security の Push Protection を一次関門に、detect-secrets で既知ノイズと新規漏洩を baseline で分離、CI で gitleaks や trufflehog を差分実行、という構成が定番です。攻撃者と同じツールを自分たちでも回す、というのが結局いちばん精度の高い予防策になります。

ツール	用途	ひと言
trufflehog	秘密検出（履歴含む）	エントロピー＋パターンで強力
gitleaks	コミット時検出	pre-commitに最適
detect-secrets (Yelp)	baseline管理	既知ノイズと新規漏洩を分離
GitHub Advanced Security	Push Protection	GitHub純正、Push段階でブロック
GH-Archive / BigQuery	大規模履歴解析	過去のpublicイベント全てが対象