◀ 用語一覧
NO.19.4

Secret Scanning

更新: 2026.10.27

一言で

Secret Scanning は、リポジトリに紛れ込んだ API キー・トークン・接続文字列を自動で見つけてくれる GitHub の検知機能。

既にコミット済みのものは アラート、これから push されるものは Push protection で git push の時点でブロック。漏洩前に止めるのが基本戦略。

なぜ private / internal repo でも secret はダメなのか

非公開でも、侵害の被害はリポジトリ内で止まらない。開発者アカウントやランナーを侵害した攻撃者は、社内に露出した secret を足掛かりに攻撃を拡大できる。secret はシークレットマネージャーで管理し、Push protection で流入を防ぐ。理由は 8 つある。

▸ + をクリックして表示

01リポジトリは社内用、開発者は社外にも

「Internal repo」は「自社社員しか触らない」を意味しない。読み取り権限があれば、社員だけでなく、業務委託先、SIer、再委託先の開発者もコミット済みの secret を読める。外部委託によって、アクセス範囲は自社の人員や管理端末の外へ広がる。

02ワンクリックで public 化

操作ミス・リポ移管・Org 設定ミス・ポリシー変更で公開に。攻撃者の自動スキャンは新規 public repo を数秒で検知、漏洩トークンが 60 秒以内に悪用された例も。

03Git 履歴は永久に残る

後続コミットで削除しても消えない。履歴・全 clone・フォーク・バックアップ・CI キャッシュに残存。唯一の対処は rotate でありファイル削除ではない。

04Git は secret も各開発端末に複製する

Git は分散型バージョン管理システム。通常の git clone は、コードと履歴に含まれる secret ごと、社員や外部委託先の各開発端末へコピーする。サーバーだけを守っても不十分。契約終了時に repo のアクセス権を削除しても、端末のコピーは消えない。

05アカウント侵害 = 即アクセス

開発者 1 人のフィッシングで、その人が読める全リポの全 secret が流出。secret 自体に MFA・保存時暗号化・有効期限などの追加保護はない。

06権限昇格とラテラルムーブメント（横展開）

社内ネットワークへの侵入後、攻撃者は private / internal repo の secret を盗み、より強い権限を獲得し、本番環境、クラウド、レジストリへ横展開できる。リポジトリを一度も公開しなくても、1 アカウントの侵害が組織全体の被害に発展し得る。 MITRE ATT&CK ↗

07コンプライアンスと監査

ISO 27001・SOC 2・PCI-DSS・ISMAP は集中管理・rotate・アクセス追跡を要求。Git に平文の secret は 3 点すべて不適合で監査指摘は確実。

08インシデントの実コスト

緊急 rotate・本番停止・フォレンジック調査・顧客通知。シークレットマネージャー設定に必要な 30 分と比べてほしい。

主な機能

DEMOSecret Scanning発表者専用

  1. PUSH PROTECTION

    ghas-test-1 で、生成した secret を push する。

    ./demo/secret-scanning/01-push-protection.sh

    push がブロックされ、ターミナルに解除用の URL が表示される。

    どのパターンを push protection の対象にするかは Enterprise 単位で制御する：octodemo → Pattern configurations ↗。Enterprise setting 列でパターンごとに ON / OFF を切り替える。Alert total・False positives・Bypass rate が並ぶので、ノイズと risk のバランスを実データで説明できる。

    GitHub default が Disabled のパターン ↗ に直接移動できる。フィルターは github-default:disabled。Enterprise の現在の設定ではなく、GitHub のデフォルト値で絞り込む。

    同じページは 何を検出するのか のスライドでも扱う（generic patterns を掘り出す）。

  2. BYPASS PUSH PROTECTION

    ブロックメッセージ内の unblock-secret URL をブラウザで開き、理由を選んで bypass する。

    理由でアラートの扱いが変わる：It's used in tests → アラートはクローズ済み（resolved as "used in tests"）で作成され、対応待ちに残らない。I'll fix it later → アラートは open のまま残り、secret の revoke / rotate が必要。

    「secret can now be pushed」と表示される。

    同じブランチをもう一度 push する。

    git push origin HEAD

    Security → Secret scanning で作成されたアラートを開き、誰が・どの理由で bypass したかを見せる。

    bypass を野放しにしない設定：ghas-test-1 → Advanced Security ↗ の Push protection → Who can bypass push protection for secret scanning を Specific roles or teams に（= Delegated bypass）。

    Org でまとめて設定：theomonfort-org → Security configuration ↗ で Push protection を Enabled、Bypass privileges を Specific actors にして対象を選ぶ。Save configuration 後、対象 repo に適用する。Org / Enterprise 側で delegated bypass を設定すると、repo 側の設定は変更できなくなる。

    申請フローは bypass 権限のない contributor で見せる（Org owner / security manager は常に bypass 可能）。ブロック画面から理由を添えて申請すると、レビュアーにメール通知が届く。

    申請一覧：ghas-test-1 → Push protection bypass requests ↗（Security and quality → Requests → Push protection bypass）。All statuses → Open で絞り込み、申請を開いて Approve bypass request / Deny bypass request を見せる。承認後は申請者が再度 push する。

    merge でも止める：ghas-test-1 → New branch ruleset ↗ で Require secret scanning alerts are resolved（Preview）を ON にする。

    I'll fix it later の secret は open アラートなので PR の merge がブロックされる。It's used in tests は止まらない。

  3. VALIDITY CHECK

    Security → Secret scanning の default ビューで Validity フィルターを使う。

    「今も有効な secret」から優先的に対応でき、実リスク順にトリアージできる。

Push protection は GitHub 上の全ブランチへの push 時にチェック。ローカルのコミット時にはチェックしない。Merge protection は PR のマージ前のチェック。

▸ + をクリックして詳細を表示

Push protectiongit push 時Docs

何をする？secret を含む push をその場で拒否。bypass は可能だが理由の記録が残る

対象範囲有効化した GitHub リポジトリの全ブランチへの push。未 push のローカルコミットは対象外。AI-detected secrets は別トグルで opt-in、private preview(招待された組織のみ)

Merge protectionPR のマージ前Changelog

設定方法Rulesets → Require secret scanning alerts are resolved を追加（Repo / Org / Enterprise）

マージ条件最新コミットのスキャン完了 + PR が持ち込む未解決アラートなし。Secret Protection / GHAS 向け public preview。ruleset の bypass は有効

使い分けgeneric patterns は push protection ではブロックせず、ruleset の対象に追加。push は許可し、PR のマージ前にアラート解消を必須にできる

Secret scanning alertsコミット後・常時Docs

何をする？検出された secret を Security and quality タブに通知

対象範囲全ブランチの Git 履歴全体・Issue・PR・GitHub Discussions・Wiki・secret gists。新しい secret type の追加時に再スキャンされる

Validity checksアラート発生時Docs

何をする？secret がまだ有効かをプロバイダー API に問い合わせ、対応の優先順位を判断できる

対象範囲一部対応プロバイダー(AWS、GitHub、Slack ほか)。AI 検出パスワードは対象外(問い合わせ先のプロバイダーがない)

Partner programpublic repo で常時 ONDocs

何をする？200+ パートナーの secret が漏れると GitHub が provider に直接通報。provider 側で revoke / 再発行される

対象範囲public repo・public npm package のみ。自分のアラート一覧には出ない(無料・設定変更不可)

Public monitoringgithub.com 全体をリアルタイムDocs

何をする？自分の repo の外(個人フォーク・OSS・公開 issue / PR)で漏れた secret を エンタープライズに帰属させて通知

対象範囲公開コンテンツのみ。private repo は絶対にスキャンしない。GHEC Enterprise 向け

何を検出するのか

DEMO検出タイプFOR PRESENTER ONLY

  1. GENERIC PATTERNS はどこに隠れているか

    octodemo → GitHub default が Disabled のパターン ↗ を開く。github-default:disabled で絞り込み済み。

    一覧はフラットで、generic とは表示されない。このフィルターは GitHub default の値で絞り込むもので、generic 専用のフィルターではない。

    名前で指し示す。この 10 個が generic patterns のすべて：

    rsa_private_key openssh_private_key ec_private_key pgp_private_key generic_private_key mongodb_connection_string mysql_connection_url postgres_connection_string http_basic_authentication_header http_bearer_authentication_header

    いずれも GitHub default は Disabled。検知は動くが、デフォルトでは push protection の対象外。

  2. CUSTOM PATTERN と DRY RUN

    ghas-test-1 → New pattern ↗ を開く（Settings → Advanced Security → Custom patterns → New pattern）。

    該当する secret はデモリポジトリに仕込み済みなので、パターンを作るだけでよい：

    Pattern name — Octodemo internal service token

    Secret format — octodemo_(live|test)_[A-Za-z0-9]{32}

    Test string — octodemo_live_L1QNGy4DLxQJ8C85kfwP0lmvCHLDuVxJ

    Test string が緑にならないと保存できない。緑になったら Save and dry run。

    dry run はアラートを作らずに仕込んだ secret を検出する。結果を確認してから Publish pattern。

  3. GENERIC / CUSTOM PATTERNS を有効化

    octodemo → Pattern configurations ↗ を開く。

    Generic: Default patterns タブで rsa_private_key などを探し、Enterprise setting を Enabled にする。

    Custom: Custom patterns タブで公開済みの Enterprise パターンを選び、Enterprise setting を Enabled にする。前の手順で作ったリポジトリ単位のパターンは、そのリポジトリの Custom patterns 設定で Push protection → Enable を選ぶ。

    有効にするのは検知ではなく push protection。デモリポジトリでも push protection が ON で、Org 側に無効化する上書き設定がなければ、該当する secret を含む新しい push がブロックされる。

検出エンジンは 4 種類。パートナー固有の厳密な形式から、AI しか拾えない非構造化 secret まで多層でカバーする。

▸ クリックして詳細を表示

Provider patterns

Provider patterns

AWS、Azure、GCP、Stripe、Slack、OpenAI、GitHub PAT など 200+ パートナーが登録した正規表現で検知。誤検知が極めて少ない。

📘 Supported secrets ↗

Generic patterns

Generic patterns

private key、接続文字列、HTTP basic auth などの汎用パターン。網が広い分、provider patterns よりトリアージ前提で運用する。デフォルトでは push protection の対象外で、Pattern configurations でパターンごとに ON にする必要がある。

AI-detected secrets

AI-detected secrets

パスワードなどの非構造化 secret を AI で検出。正規表現では届かない領域をカバーする。Push protection は別トグルで private preview(招待された組織のみ)。Validity check は非対応なので、アラートとしてトリアージする。
🔎 アラートは Generic タブに表示。

Custom patterns

Custom patterns

自社独自のトークン形式に正規表現を定義。社内サービスのトークンやレガシーな認証情報など、パートナーが登録しないものを拾う。
🔎 Default 一覧に表示。Secret type フィルターで絞り込む。

📘 Defining custom patterns ↗

タイプを選択 ▸

漏洩した secret の対応方法

DEMOSecurity campaigns発表者専用

  1. CAMPAIGNS タブ

    theomonfort-org → Campaigns ↗ を開く。

    トラッキング画面。各 campaign の 期限・担当者・未対応 / 対応済みの消化状況が並ぶ。伝えたいのは アラートに担当者と期限が付く場所がここ（スプレッドシートではない）ということ。

  2. SECRET SCANNING フィルターから作成

    Create campaign → From secret scanning filters

    その場でフィルターを組み立てて絞り込みの考え方を見せる。is:open から始め、対象リポジトリを絞り、Validity で Active と Unknown を選ぶ。

    フィルターを足すたびに件数が減るのを見せる。これが要点で、バックログではなく終われるリストになる。保存できるのは 1000 alerts まで。

  3. 名前・期限・公開

    Save as → Draft campaign で下書きし、名前・説明・期限・campaign manager を入力。

    manager の候補に org owner と security manager しか出ないことに触れる。

    Review and publish でアラートを見られる人全員に通知が飛び、各リポジトリの Security タブに campaign が出る。secret campaign が public preview であることも一言添える。

Secret が見つかった時にやることは 検知より修復が大事。規模が大きいときは生のアラート一覧を追わず、security campaign として回す。

▸ ステップをクリックして詳細を表示

対象を絞る

🎯 SCOPE — 重要リポジトリから

Org → Security and quality → Campaigns → Create campaign → From secret scanning filters

組織全体ではなく重要なリポジトリに絞る。リポジトリのカスタムプロパティ(props.BusinessPriority:Urgent)が使いやすい。1000 alerts が上限であり、目安でもある。

優先度をつける

⚡ TRIAGE — 実リスク順に

validity を Active と Unknown に絞る。Active は今すぐ悪用できる生きた鍵。Unknown は無効と確認できていないので、生きている前提で扱う。

Inactive は後回しでよい。これでバックログが「片付ける価値のあるリスト」になる。

担当と期限

👤 OWN — 担当者と期限を決める

campaign には必ず 期限 と campaign manager を設定する。manager に指定できるのは org owner と security manager のみ。

どちらか欠けると rotate は進まない。公開するとアラートを見られる人全員に通知が飛び、各リポジトリの Security タブに campaign が出る。

rotate して close

🚨 ROTATE — 無効化してクローズ

リポジトリから消すだけでは不十分で、履歴と他人の clone に残り続ける。

public repo で漏れた partner secret は provider 側で revoke され、自分のアラート一覧には出ない。最後に Revoked / False positive / Used in tests で close し、campaign を消化する。

ステップを選択 ▸

私のおすすめ導入チェックリスト 📖 Docs

DEMOSecret Scanning checklist発表者専用

  1. 1. 社内独自の SECRET パターン

    ghas-test-1 → New custom pattern ↗: Secret format、Test string を見せ、公開前に Save and dry run で確認。

  2. 2. PUSH PROTECTION の対象

    octodemo → Pattern configurations ↗: False positives、Bypass rate と Enterprise setting 列を確認。

  3. 3. MERGE 前の別ルール

    ghas-test-1 → New branch ruleset ↗: Require secret scanning alerts are resolved → Generic patterns を選択。対象は main。画面紹介では ruleset を Disabled のままにする。

  4. 4. PUSH PROTECTION の BYPASS

    octodemo → Security configurations ↗: 対象の configuration を開き、Push protection → Bypass privileges → Specific actors を確認。

    Enterprise 設定は他の repo にも影響する。閲覧デモでは変更を保存、適用しない。

  5. 5. SECRET 対応の CAMPAIGN

    theomonfort-org → Campaigns ↗: Create campaign → From secret scanning filters。対象を ghas-test-1 に絞り、draft で保存。

    ghas-test-1 → Secret scanning alerts ↗

  6. 6. ワークフローの SECRET を登録

    ghas-test-1 → Actions secrets ↗: New repository secret を見せる。画面共有中に本物の secret は入力しない。

Secret Protection と push protection を有効化したら、この順番で進めるのがおすすめ。

▸ 完了したステップにチェック。ステップを開くと設定リンクを表示

1社内独自の secret があればパターンを追加CUSTOM PATTERNSDocs

設定New custom pattern ↗: トークン形式を dry run で確認してから公開。

2Push protection のブロック対象を決めるPATTERNSDocs

確認Pattern dashboard ↗: 誤検知率と bypass 率を見て、ブロックするパターンを選ぶ。

3Merge 前に別の保護ルールを追加MERGE PROTECTIONDocs

例Rulesets ↗: Require secret scanning alerts are resolved → Generic patterns を選択。Push は許可し、main への merge 前にアラート解決を必須にする。Ruleset の bypass は別設定。Public preview。

4Push protection の bypass 権限を決めるENTERPRISEDocs

制限Enterprise configurations ↗: Bypass privileges → Specific actors を設定し、保存して適用。

5既存の secret に対応する campaign を作るCAMPAIGNSDocs

対応Security campaigns ↗: secret scanning アラートを選び、担当と期限を決めて revoke / rotate。

6ワークフローの secret は GitHub に登録ACTIONS SECRETSDocs

保存Actions secrets ↗: コードに書かず、Settings → Secrets and variables → Actions → New repository secret で登録。

URL テンプレート内の ENTERPRISE、ORG、OWNER、REPO を置き換えて使う。

利用条件と製品

機能 Public repo Private / internal
製品なし		 Secret Protection / GHAS
Secret scanning alerts✅ 無料❌✅ 含む
Push protection（リポ / 組織）✅ 無料❌✅ 含む
Partner program alerts（provider に通知）✅ 無料・常時 ON❌❌ public repo のみ
Validity checks❌❌✅ 対応 provider
Generic patterns❌❌✅ 含む
Custom patterns❌❌✅ 含む
AI-detected secrets❌❌✅ 含む
Public monitoring❌❌✅ GHEC Enterprise

🆓 ユーザー push protection は全プランで無料・デフォルト ON だが、public repo への push のみが対象。Partner alerts も public repo / public npm package の漏洩だけを provider に通知する(常時 ON、設定変更は不可)。

👤 ユーザー所有リポジトリ は例外扱い。アラートには GHEC の Enterprise Managed Users、または Secret Protection を有効にした GHES が必要。Org 所有の private / internal repo なら Team / GHEC で Secret Protection があれば良い。

💰 Generic / Custom / AI detection、Validity checks、private / internal repo の保護には Secret Protection または従来の GHAS が必要。Public monitoring は GHEC Enterprise 向けの enterprise-wide 機能。

📘 詳細: Advanced Security products ↗ / Partner program ↗ / Public monitoring ↗

Public monitoring（NEW） 📖 Docs

  • 🌐 公開コンテンツのみ（git・PR・issue・discussion）。自分の repo の外の漏洩を拾う
  • ⚡ リアルタイム監視。Secret Protection / GHAS 対象、追加費用なし
  • 🧩 設定不要。有効化した時点で既存の finding も出る
帰属の方式判定捕捉できる漏洩
👤 メンバー帰属committer がメンバー管理・既知アカウント
🌐 検証済みドメイン自社ドメインの email仕事用 email の個人

⚙️ Security and quality から enterprise owner / security manager が有効化する。

Secret Risk Assessment 📖 Docs

Org 全体をスキャンし、secret の在りかを可視化。Team / Enterprise は無料。

  • 🔎 対象 — Org の全リポジトリ。visibility 問わず、アーカイブ済みも含む
  • 📊 出力 — secret の種類と件数を repo ごとに集計。値は保存も表示もされない
  • 🕒 頻度 — point-in-time。Rerun scan で 90 日ごとに再実行。継続監視ではない
  • 🚀 実行 — Org → Security and quality → Assessments → Scan your organization。初回は無料の code security assessment も走る

📊 「社内に何件漏れているか」を知る用途と、予算稟議の数字づくりに使う。

スライド Eng