一言で
Secret Scanning は、リポジトリに紛れ込んだ API キー・トークン・接続文字列を自動で見つけてくれる GitHub の検知機能。
既にコミット済みのものは アラート、これから push されるものは Push protection で git push の時点でブロック。漏洩前に止めるのが基本戦略。
なぜ private / internal repo でも secret はダメなのか
非公開でも、侵害の被害はリポジトリ内で止まらない。開発者アカウントやランナーを侵害した攻撃者は、社内に露出した secret を足掛かりに攻撃を拡大できる。secret はシークレットマネージャーで管理し、Push protection で流入を防ぐ。理由は 8 つある。
主な機能
-
PUSH PROTECTION
ghas-test-1で、生成した secret を push する。./demo/secret-scanning/01-push-protection.shpush がブロックされ、ターミナルに解除用の URL が表示される。
どのパターンを push protection の対象にするかは Enterprise 単位で制御する:octodemo → Pattern configurations ↗。Enterprise setting 列でパターンごとに ON / OFF を切り替える。Alert total・False positives・Bypass rate が並ぶので、ノイズと risk のバランスを実データで説明できる。
同じページは 何を検出するのか のスライドでも扱う(generic patterns を掘り出す)。
-
BYPASS PUSH PROTECTION
ブロックメッセージ内の
unblock-secretURL をブラウザで開き、理由を選んで bypass する。「secret can now be pushed」と表示される。
同じブランチをもう一度 push する。
git push origin HEADSecurity → Secret scanning のクローズ済みアラートを開き、誰が・どの理由で bypass したかを見せる。
bypass を野放しにしない設定:
Settings → Advanced Security → Push protectionで Who can bypass push protection を Specific roles or teams に(= Delegated bypass)。 -
VALIDITY CHECK
Security → Secret scanning の default ビューで Validity フィルターを使う。
「今も有効な secret」から優先的に対応でき、実リスク順にトリアージできる。
Secret Scanning は 5 つの機能で構成される。入口を塞ぐ Push protection が最優先で、残りは検知・対応・provider 連携を支える。
何を検出するのか
-
GENERIC PATTERNS はどこに隠れているか
octodemo → Pattern configurations ↗ を開き、default patterns タブをスクロールする。
一覧はフラット。カテゴリ列も provider / generic の区別も絞り込みもない。generic patterns は確かに存在するが、generic とは表示されない。
名前で指し示す。この 10 個が generic patterns のすべて:
rsa_private_keyopenssh_private_keyec_private_keypgp_private_keygeneric_private_keymongodb_connection_stringmysql_connection_urlpostgres_connection_stringhttp_basic_authentication_headerhttp_bearer_authentication_headerいずれも GitHub default は Disabled。検知は動くが push protection は効かない。Enterprise setting 列で ON にして初めて対象になる。
-
CUSTOM PATTERN と DRY RUN
Settings → Advanced Security → Custom patterns → New pattern該当する secret はデモリポジトリに仕込み済みなので、パターンを作るだけでよい:
Pattern name —
Octodemo internal service tokenSecret format —
octodemo_(live|test)_[A-Za-z0-9]{32}Test string —
octodemo_live_L1QNGy4DLxQJ8C85kfwP0lmvCHLDuVxJTest string が緑にならないと保存できない。緑になったら Save and dry run。
dry run はアラートを作らずに仕込んだ secret を検出する。結果を確認してから Publish pattern、必要なら push protection も ON にする。
検出エンジンは 4 種類。パートナー固有の厳密な形式から、AI しか拾えない非構造化 secret まで多層でカバーする。
漏洩した secret の対応方法
-
CAMPAIGNS タブ
theomonfort-org → Campaigns ↗ を開く。
トラッキング画面。各 campaign の 期限・担当者・未対応 / 対応済みの消化状況が並ぶ。伝えたいのは アラートに担当者と期限が付く場所がここ(スプレッドシートではない)ということ。
-
SECRET SCANNING フィルターから作成
Create campaign → From secret scanning filtersその場でフィルターを組み立てて絞り込みの考え方を見せる。
is:openから始め、対象リポジトリを絞り、Validity で Active と Unknown を選ぶ。フィルターを足すたびに件数が減るのを見せる。これが要点で、バックログではなく終われるリストになる。保存できるのは 1000 alerts まで。
-
名前・期限・公開
Save as → Draft campaign で下書きし、名前・説明・期限・campaign manager を入力。
manager の候補に org owner と security manager しか出ないことに触れる。
Review and publish でアラートを見られる人全員に通知が飛び、各リポジトリの Security タブに campaign が出る。secret campaign が public preview であることも一言添える。
Secret が見つかった時にやることは 検知より修復が大事。規模が大きいときは生のアラート一覧を追わず、security campaign として回す。
始め方(最短ルート)
Settings → Advanced Security
▸ STEP 1 · PUSH PROTECTION
これから入る secret を push 時にブロック。
Security → Secret scanning
▸ STEP 2 · 既存の漏洩
過去の履歴も自動スキャン。上から rotate。
… → Custom patterns
▸ STEP 3 · CUSTOM PATTERNS
自社独自のトークン形式を正規表現で登録。
Org → … → Configurations
▸ STEP 4 · 全体展開
設定 1 つで Org / Enterprise 全体に一括適用。
⚠️ 旧来の Org REST API フィールドは 2026-04-21 に削除済み。security configurations API を使う。
利用条件と製品
| 機能 | 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 も走る
📊 「社内に何件漏れているか」を知る用途と、予算稟議の数字づくりに使う。