GitHub secret scanning の coverage update を一言でいうと、検出できる secret の種類が増え、push 前に止められる範囲も広がり、さらに一部トークンは「今すぐ危ないか」を判断しやすくなった更新です。2026年3月31日の changelog では、7プロバイダ・9種類の新しい detector 追加、npm_access_token への validity checks 対応、そして一部パターンの push protection 既定対象化が公開されました。漏えい対策の観点では、後追い検知、事前ブロック、修復の優先順位付けの3つが同時に前進したと見てよい内容です。(The GitHub Blog)
ただし、coverage update は万能ではありません。GitHub は新しい secret type が追加されるとリポジトリを定期的に再スキャンしますが、ペア型の認証情報は同じファイル・同じリポジトリ内にそろっていないと検出されない場合があります。また、組織独自の token や命名規則は default pattern だけでは拾いきれず、custom patterns で補う必要があります。この記事では、今回何が新しく検出対象になるのか、既存運用にどんな影響が出るのか、見逃しを減らすために何を見直すべきかを実務目線で整理します。(GitHub Docs)
GitHub secret scanning の coverage update で何が変わったか
2026年3月31日の更新で押さえるべき変更点は、次の4つです。9つの新規 detector 追加、npm_access_token の validity checks 追加、4つの pattern を push protection の既定対象に追加、そして push protection 設定画面から該当 pattern の alert 一覧へ直接飛べる UI 改善 です。加えて、Drone CI、Netlify、Pydantic、Twitch 向け detector は observation mode とされており、検証後に一般提供へ昇格予定です。(The GitHub Blog)
今回追加された9つの detector
今回追加された detector は次の9種類です。(The GitHub Blog)
fieldguide_api_token（push protection は configurable）figma_scim_token（push protection は default）flickr_api_key（push protection は configurable）hackclub_ai_api_key（push protection は configurable）langsmith_license_key（push protection は default）langsmith_scim_bearer_token（push protection は default）posthog_oauth_access_token（push protection は configurable）posthog_oauth_refresh_token（push protection は configurable）salesforce_marketing_cloud_api_oauth2_token（push protection は default）
ここで実務上のポイントは、ただ alert が増えるだけではなく、追加された detector の一部が最初から push protection 対象になっていることです。特に figma_scim_token は、新規 detector の一覧にも、push protection 既定対象の一覧にも含まれており、Figma の SCIM 連携を使う組織では影響を受けやすい更新です。(The GitHub Blog)
npm と push protection で強くなった点
新たに validity checks が追加されたのは npm_access_token です。validity checks は、検出した secret がまだ active かどうかを確認し、active、inactive、unknown といった状態で優先順位付けを助ける機能です。npm を使うリポジトリでは、見つかった token を全部同じ重みで扱うのではなく、active と確認されたものから先にローテーションする運用に寄せやすくなります。(The GitHub Blog)
また、push protection の既定対象に加わったのは figma_scim_token、google_gcp_api_key_bound_service_account、openvsx_access_token、posthog_personal_api_key の4種類です。push protection が有効な環境では、これらの pattern に一致した commit は push 時点でブロックされます。(The GitHub Blog)
誤解しやすいのは、「push protection defaults」が push protection 機能そのものの自動有効化を意味しないことです。repository 向け push protection 自体は引き続き disabled by default で、repo・organization・enterprise のいずれかで有効化が必要です。今回の更新は、push protection を使っている環境で、既定のブロック対象が広がったと理解するのが正確です。(The GitHub Blog)
GitHub Advanced Security / GitHub Secret Protection では誰が影響を受けるか
現在、secret scanning と push protection は GitHub Advanced Security の secret 側製品である GitHub Secret Protection に含まれます。public repository では secret scanning は自動で無料実行されますが、organization-owned の private / internal repository で本格的に使うには、GitHub Team または GitHub Enterprise Cloud 上で GitHub Secret Protection が必要です。(GitHub Docs)
そのため今回の coverage update は、公開リポジトリの保守者には追加設定なしで効く部分がある一方、private / internal repository では Secret Protection の有効化状況に応じて効き方が変わるアップデートです。GitHub Advanced Security を「コードスキャン中心の製品」と捉えていた組織ほど、secret scanning 側の見直しが必要になります。(The GitHub Blog)
GitHub secret scanning の検出範囲拡大で、漏えい対策はどこまで強くなる？
既存コードの見逃し削減には確実に効く
GitHub secret scanning は、リポジトリの全ブランチにある Git 履歴全体を走査し、新しい secret type が追加されると定期的に再スキャンします。さらに、対象はコード本体だけでなく、issue、pull request、Discussions、wiki、secret gist にも及びます。つまり今回の detector 追加は、これから混入する漏えいだけでなく、過去に埋もれていた漏えいが今になって見つかる可能性を高めます。(GitHub Docs)
この点が今回の update のいちばん大きい実務価値です。coverage が広がると、「運用を変えていないのに alert が増えた」という現象が起きますが、それは悪化ではなく、今まで見えていなかった露出が見えるようになったという意味です。特に Figma、Langchain、PostHog、Salesforce Marketing Cloud などを使っているチームは、既存 repo の再確認を優先したほうが安全です。(The GitHub Blog)
事前ブロックも一段強くなる
push protection は、secret scanning の事後検知版ではなく、push 時に secret を見つけて止める予防機能です。CLI からの push だけでなく、GitHub UI 上の commit、ファイルアップロード、REST API 経由の更新なども対象になります。今回の default 対象拡大で、既に push protection を運用している組織は、追加設定なしでブロックできる範囲が広がります。(GitHub Docs)
ここで重要なのは、coverage update が「検知の網」を広げるだけでなく、レビュー前に漏えいを止める面も強化していることです。事後 alert は remediation が必要ですが、push protection はそもそも流出を repository に到達させません。漏えいコストの大きい secret ほど、後追い検知より前段ブロックのほうが運用負荷を下げやすいです。(GitHub Docs)
npm token は「何から直すか」が判断しやすくなる
validity checks は、見つけた secret がまだ有効かどうかを GitHub が issuer 側と照合して確認する仕組みです。alert 画面では active、inactive、unknown といった形で状態を見られるため、「とりあえず全部調べる」から「active を先に塞ぐ」へ運用を変えやすくなります。(GitHub Docs)
今回 npm_access_token がこの対象に加わったことで、npm を使う組織では、publish 用 token や自動化用 token の remediation 優先度をつけやすくなります。特に alert 件数が多い repo では、validity checks の有無が triage の速度をかなり左右します。(The GitHub Blog)
それでも見逃しがゼロになるわけではない
secret scanning にはもともと検出上の制約があります。たとえば AWS のような pair pattern は、ID と secret の両方が同じファイルにあり、同じ repository に push されていないと alert になりません。片方だけ別ファイルにある、別 repo に分散している、といった構成は見逃し得ます。coverage update は強化ですが、検出ロジック上の blind spot を消すものではありません。(GitHub Docs)
また、default pattern だけでは組織固有の token を拾えません。GitHub は non-provider patterns、custom patterns、Copilot secret scanning による generic secret 検出も提供しており、default coverage の外側は自分たちで埋める設計です。「GitHub が増やしてくれる検出範囲」と「自社で定義すべき検出範囲」を分けて考えるのが運用のコツです。(GitHub Docs)
既存運用で起きやすい変化と対策
今回の更新で現場に起きやすい変化を、運用目線で整理すると次のとおりです。(GitHub Docs)
| 起きやすい変化 | 背景 | 先に決めておくべきこと |
|---|---|---|
| 突然 alert が増える | 新しい secret type 追加時に再スキャンが走る | 追加 provider を使う repo の棚卸し、担当チームへの振り分け |
| push が止まるケースが増える | default push protection 対象が広がる | false positive 時の連絡先、bypass 基準、owner 通知の扱い |
| npm alert の優先度が変わる | validity checks で active / inactive / unknown が付く | active を最優先にローテーションする運用 |
| 「alert がない=安全」と誤解しやすい | partner alert は repo 画面に出ない | repo alert と partner alert の違いを運用手順に明記 |
特に見落としやすいのが alert の種類の違い です。secret scanning には user alerts、push protection alerts、partner alerts の3種類があり、partner alerts は provider に直接通知され、repository の Security and quality tab には表示されません。つまり、repo 上に alert が見えないことと、検出されていないことは同義ではありません。(GitHub Docs)
もう1つ大事なのが remediation の順番です。GitHub docs は、secret を見つけたらまず資格情報を rotation することを推奨しており、Git 履歴からの完全削除は時間がかかるうえ、既に revoke 済みなら必須でない場合もあります。現場では「履歴の掃除」から始めがちですが、優先すべきは利用停止・再発行です。(GitHub Docs)
push protection を使っている組織では、bypass 時の扱いも見直したいところです。GitHub は bypass が起きると alert を作成し、audit log に記録し、関係者へメール通知します。さらに bypass reason が「used in tests」「false positive」の場合は closed alert、「I’ll fix it later」の場合は open alert になります。新しい default pattern が増えるほど、この差は運用負荷に直結します。(GitHub Docs)
見逃しをさらに減らすために今やるべき5つの見直し
追加された provider を使っている repo をまず棚卸しする
最初にやるべきは、今回追加された 7 provider の利用有無を repo 単位で洗い出すことです。Fieldguide、Figma、Flickr、Hack Club、Langchain、PostHog、Salesforce Marketing Cloud を使っている repo は、再スキャンによる新規 alert や push block の影響を受けやすい対象です。最初から全社横断で見るより、該当サービスを使っている repo だけ先に見るほうが速く、反応漏れも減ります。(The GitHub Blog)
組織の secret risk assessment を回して、優先順位を決める
GitHub Team / Enterprise の organization なら、GitHub Secret Protection の有効化状況に関係なく、secret risk assessment を無料で実行できます。Security and quality タブの Assessments から Scan your organization を実行でき、再実行は 90 日ごとです。coverage update の直後は、全部の repo を同じ温度感で追うより、assessment で露出の多い領域を見つけるほうが現実的です。(GitHub Docs)
push protection の pattern 設定を「件数」ではなく「質」で見直す
push protection の設定画面では、pattern ごとに alert total、false positive rate、bypass rate、GitHub default などの情報を確認できます。今回から pattern type 名が該当 alert list へ直接リンクするようになったため、「どの pattern が本当に役立っていて、どの pattern が開発体験を荒らしているか」 を以前より判断しやすくなりました。configurable pattern を全部オンにするのではなく、bypass rate と false positive のバランスで決めるのが失敗しにくい方法です。(GitHub Docs)
npm を使う repo では validity checks を有効化して triage を変える
npm_access_token が validity checks に対応したからといって、どの repo でも自動で優先順位付けが良くなるわけではありません。validity checks は有効化が必要で、organization-owned repo では GitHub Team / Enterprise Cloud と GitHub Secret Protection が前提です。npm を多く使う repo では、alert を開いたらまず status を見て、active から処理するルールに変えるだけでも対応速度が上がります。(GitHub Docs)
default pattern で拾えない secret は custom patterns で埋める
coverage update はありがたい一方で、組織固有の credential 命名は相変わらず自分たちで定義するしかありません。GitHub は custom patterns の push protection も提供していますが、よく出現する文字列を block 対象にすると contributor にとってはかなり disruptive です。docs でも、custom pattern を push protection に乗せる前に dry run を行うこと、よく見かける pattern の有効化には注意することが勧められています。今回の update を機に default coverage を喜ぶだけで終わらず、足りない範囲を custom pattern で埋めるのが、本当に見逃しを減らすやり方です。(GitHub Docs)
まとめ
今回の GitHub secret scanning coverage update は、単なる「対応サービスが増えました」という話ではありません。9つの detector 追加で検知の網が広がり、4つの default push protection pattern で事前防止が強くなり、npm_access_token の validity checks で triage がしやすくなった、かなり実務寄りの改善です。特に、GitHub が新しい secret type 追加時に repo を再スキャンする点を踏まえると、既存運用への影響は小さくありません。(The GitHub Blog)
次にやることは明確です。追加された provider を使っている repo を棚卸しし、assessment で優先順位を取り、push protection の pattern 設定と npm validity checks を見直し、default で拾えないものは custom patterns で補う。 この順番で動けば、今回の coverage update を「お知らせ」で終わらせず、実際の漏えいリスク低減につなげやすくなります。(GitHub Docs)
コメント