2026年6月17日に公開されたGitHub Changelog「Secret scanning updates – June 2026」では、Secret scanningに20種類の新規検出パターン、9種類のPush protection既定パターン、24種類のValidity checks、5種類のExtended metadata対応が追加されました。
利用者側でGitHubクライアントなどを更新する必要はありません。ただし、既存のGit履歴から新しいアラートが検出されたり、これまで通っていたpushがブロックされたりする可能性があります。今回の告知には、移行期限や料金改定の記載はありません。管理者は設定状況と新規アラートを確認しておきましょう。(The GitHub Blog)
GitHub ChangelogのSecret scanning updates – June 2026で変わったこと
今回の変更は、次の4点に整理できます。
| 変更項目 | 変更内容 | 主な影響 |
|---|---|---|
| 新しい検出パターン | 20種類を追加 | 過去のGit履歴から新規アラートが出る可能性がある |
| Push protection | 9種類を既定のブロック対象に追加 | 対象シークレットを含むpushが止まる |
| Validity checks | 24種類を追加 | 漏えいした認証情報が現在も有効か判断しやすくなる |
| Extended metadata | 5種類を追加 | シークレットの所有者や影響範囲を特定しやすくなる |
単なる「検出できる種類の追加」ではありません。開発者にはpush時の挙動変更、管理者にはアラートの優先順位付けやインシデント対応の効率化という影響があります。
新たに20種類のシークレットを検出
Secret scanningが新たに検出できるようになったシークレットは、次のとおりです。CloudsmithとMerakiは、新しいSecret scanningパートナーとして追加されています。(The GitHub Blog)
| プロバイダー | 追加されたSecret type |
|---|---|
| Cloudsmith | cloudsmith_api_key |
| Datadog | datadog_pat、datadog_sat |
| Elastic | elastic_stack_api_key |
| GitLab | gitlab_ci_build_token、gitlab_deploy_token、gitlab_feature_flag_client_token、gitlab_feed_token_v2、gitlab_incoming_email_token、gitlab_kubernetes_agent_token、gitlab_oauth_app_secret、gitlab_pipeline_trigger_token、gitlab_runner_auth_token、gitlab_runner_registration_token、gitlab_scim_oauth_token |
| Meraki | meraki_api_key |
| Slack | slack_workflow_trigger_url |
| Supabase | supabase_oauth_access_token、supabase_scoped_personal_access_token |
| VolcEngine | volcengine_ark_api_key |
特に影響が大きいのはGitLabです。CI/CD、デプロイ、Runner、Kubernetes Agent、OAuthアプリなど、運用で使われやすい11種類のトークンが対象になりました。
過去に削除したトークンも検出される可能性がある
Secret scanningは現在のファイルだけでなく、リポジトリ内の全ブランチにあるGit履歴もスキャンします。GitHubは新しいシークレットタイプを追加した際、既存リポジトリを定期的に再スキャンします。(GitHub Docs)
そのため、現在のソースコードから削除済みでも、過去のコミットにGitLab Deploy TokenやSlack Workflow Trigger URLが残っていれば、新しいアラートが発生する可能性があります。
新規アラートが出た場合は、次の順番で対応してください。
- シークレットが現在も有効か確認する
- 有効な場合は発行元サービスで失効またはローテーションする
- 新しいシークレットを利用先へ反映する
- 不正利用や想定外のアクセスがなかったかログを確認する
- 必要に応じてGit履歴からシークレットを削除する
- 対応完了後にSecret scanningアラートを閉じる
現在のファイルから文字列を削除するだけでは、認証情報自体は無効になりません。GitHubも、漏えいしたシークレットは侵害されたものとして扱い、まず失効させることを推奨しています。(GitHub Docs)
Push protectionの既定ブロック対象が9種類追加
以下の9種類が、Push protectionの既定パターンに追加されました。GitHubは、Secret scanningが有効なリポジトリについて、無料の公開リポジトリを含め、これらのシークレットを含むコミットを自動的にブロックすると説明しています。(The GitHub Blog)
| プロバイダー | 既定のブロック対象になったSecret type |
|---|---|
| Cloudflare | cloudflare_account_api_token、cloudflare_global_user_api_key、cloudflare_user_api_token |
| Cockroach Labs | ccdb_api_key |
| Flutterwave | flutterwave_test_api_secret_key |
| Hack Club | hackclub_ai_api_key |
| OpenRouter | openrouter_api_key |
| PostHog | posthog_oauth_refresh_token |
| Supabase | supabase_personal_access_token |
これまで同じコードをpushできていた場合でも、更新後はpushが拒否される可能性があります。
たとえば、OpenRouterのAPIキーをアプリケーション設定ファイルへ直接記載している場合、今後はコミット時点でブロックされます。値を削除したうえで、GitHub ActionsのRepository secretsや利用中のシークレット管理サービスへ移してください。
テスト用キーでも安易にバイパスしない
flutterwave_test_api_secret_keyのように、名前に「test」が含まれるシークレットも対象です。テスト環境用であっても、外部サービスへアクセスできる認証情報なら、リポジトリへ直接保存すべきではありません。
Push protectionの警告が出たときは、次の基準で判断します。
| 状況 | 推奨する対応 |
|---|---|
| 実際に使用できるAPIキーやトークン | コミットから削除し、失効またはローテーションする |
| ドキュメント用のダミー値 | 明らかに無効なプレースホルダーへ置き換える |
| 自動テストで使う認証情報 | GitHub ActionsのSecretsなどへ移す |
| 誤検知の可能性が高い文字列 | シークレット所有者または管理者が確認してからバイパスする |
| 後で修正する予定 | バイパスせず、push前に修正する |
リポジトリ単位のPush protectionでは、バイパス時にアラートや監査ログが作成される場合があります。常態的にバイパスが発生している場合は、開発フローやテストデータの見直しが必要です。(GitHub Docs)
Validity checksが24種類のシークレットに対応
Validity checksは、検出したシークレットが現在も利用可能かを確認する機能です。今回、次の24種類が新たに対応しました。(The GitHub Blog)
| プロバイダー | 対応したSecret type |
|---|---|
| Alibaba | alibaba_cloud_access_key_id、alibaba_cloud_access_key_secret |
| Azure | azure_ai_services_key、azure_anomaly_detector_ee_key、azure_anomaly_detector_key、azure_cognitive_services_key、azure_content_moderator_key、azure_cosmosdb_key_identifiable、azure_custom_vision_prediction_key、azure_custom_vision_training_key、azure_event_hub_key_identifiable、azure_function_key、azure_relay_key_identifiable、azure_service_bus_identifiable、azure_storage_account_key、azure_text_translation_key |
| Coveo | coveo_access_token、coveo_api_key |
| Databricks | databricks_access_token |
| Salesforce | salesforce_access_token |
| Shopify | shopify_access_token、shopify_custom_app_access_token、shopify_merchant_token、shopify_private_app_password |
Validity checksを有効にすると、アラート上で主に次の状態を確認できます。
| 表示 | 意味 | 対応の目安 |
|---|---|---|
active | 現在も利用できる可能性が高い | 最優先で失効・ローテーションする |
inactive | 無効化済み、または利用できない | 履歴や影響範囲を確認してアラートを整理する |
unknown | 有効性を判定できない | 安全と判断せず、発行元サービスで確認する |
GitHubはValidity checksを有効にした環境で、検出した認証情報を発行元サービスのAPIへ送信し、定期的に有効性を確認します。判定できない場合もあるため、最終的な確認先は認証情報の発行元サービスです。(GitHub Docs)
Validity checksは設定を有効にする必要がある
対応パターンが増えただけでは、すべてのアラートに自動で有効性が表示されるとは限りません。リポジトリでValidity checksを有効にする手順は次のとおりです。
- 対象リポジトリの「Settings」を開く
- 「Security」内の「Advanced Security」を開く
- 「Secret Protection」内の「Validity checks」を有効にする
- 画面下部の「Save changes」を選択する
Validity checksは、GitHub TeamまたはGitHub EnterpriseでGitHub Secret Protectionを有効にした組織所有リポジトリで利用できます。(GitHub Docs)
Extended metadataが5種類のシークレットに対応
Extended metadataの対象には、次の5種類が追加されました。(The GitHub Blog)
| プロバイダー | 対応したSecret type |
|---|---|
| Airtable | airtable_api_key、airtable_personal_access_token |
| Grafana | grafana_cloud_api_token |
| npm | npm_access_token |
| xAI | xai_api_key |
Extended metadataを利用すると、発行元がGitHubへ提供する情報に応じて、シークレットの所有者や影響範囲など、対応判断に役立つ追加情報を確認できます。
たとえばnpm Access Tokenが漏えいした場合、単に「トークンが見つかった」という情報だけでなく、所有者や影響を受ける対象を特定しやすくなれば、担当チームへの連絡やパッケージ公開権限の確認を迅速に進められます。
ただし、取得できる情報はプロバイダーごとに異なります。また、Extended metadata checksはパブリックプレビューであり、今後仕様が変わる可能性があります。(GitHub Docs)
Extended metadataを有効にする手順
Extended metadataを有効にするには、先にValidity checksを有効化しておく必要があります。
- リポジトリの「Settings」を開く
- 「Security」から「Advanced Security」を開く
- 「Secret Protection」でValidity checksが有効か確認する
- 「Extended metadata」を有効にする
複数のリポジトリを管理している場合は、リポジトリごとに設定するより、OrganizationまたはEnterpriseのSecurity configurationsから一括適用した方が設定漏れを防ぎやすくなります。(GitHub Docs)
誰に影響する変更なのか
今回のGitHub Secret scanning更新は、対象プロバイダーのサービスを利用している開発者だけでなく、リポジトリ管理者やセキュリティ担当者にも影響します。
| 対象者 | 想定される影響 | 確認すること |
|---|---|---|
| 開発者 | pushが新たにブロックされる | APIキーをハードコードしていないか |
| リポジトリ管理者 | 過去のGit履歴から新規アラートが出る | Secret scanningアラートと設定状態 |
| Organization管理者 | リポジトリごとに設定が異なる可能性がある | Security configurationsの適用範囲 |
| セキュリティ担当者 | 有効なシークレットを優先処理しやすくなる | validity:activeのアラート |
| API・SIEM連携の管理者 | 新しいSecret typeが連携データに現れる | 固定リストや振り分けルール |
| 公開リポジトリの所有者 | 無料のSecret scanningで検出対象が増える | 公開リポジトリ内の新規アラート |
REST APIやSIEMでsecret_typeを使って分類している場合は、新しく追加された値を処理できるか確認してください。既知のSecret typeだけを列挙した条件分岐を使っていると、新しいタイプが未分類になる可能性があります。未知の値も受け入れられる設計にしておくと、今後のパターン追加にも対応しやすくなります。(GitHub Docs)
設定とアラートを確認する手順
管理者は、次の順番で確認すると見落としを減らせます。
Secret ProtectionとPush protectionを確認する
対象リポジトリで以下の画面を開きます。
Settings → Security → Advanced Security
確認項目は次の4つです。
| 確認項目 | 判断基準 |
|---|---|
| Secret Protection | PrivateまたはInternalリポジトリでSecret scanningを使う場合に必要 |
| Push protection | 新しいコミットへのシークレット混入を防ぐため有効化を推奨 |
| Validity checks | アクティブな認証情報を優先して対応したい場合に有効化 |
| Extended metadata | 所有者や影響範囲などの追加情報が必要な場合に有効化 |
Secret Protectionは、リポジトリの「Settings」から「Advanced Security」を開き、「Secret Protection」の「Enable」で有効化できます。Push protectionも同じ画面から設定できます。(GitHub Docs)
新しいSecret scanningアラートを確認する
アラートは、対象リポジトリの以下の画面で確認できます。
Security and quality → Vulnerability alerts → Secret scanning
今回の更新後は、次のフィルターが役立ちます。
| フィルター例 | 用途 |
|---|---|
sort:created-desc | 新しく作成されたアラートから確認する |
validity:active | 現在も有効なシークレットを絞り込む |
validity:unknown | 有効性を判定できないアラートを確認する |
provider:gitlab | GitLab関連のアラートを絞り込む |
secret-type:openrouter_api_key | 特定のSecret typeだけを表示する |
bypassed:true | Push protectionがバイパスされたアラートを確認する |
Validity checksを有効にしていない場合、GitHubトークン以外ではvalidityによる絞り込みが十分に機能しないことがあります。(GitHub Docs)
更新・移行・料金・期限の確認事項
アプリやワークフローの更新は原則不要
今回の変更はGitHub側の検出パターン追加です。GitHub Desktop、Gitクライアント、GitHub Actionsのバージョンアップや、リポジトリデータの移行作業は案内されていません。
ただし、次の運用は見直す必要があります。
- Secret typeを固定リストで管理しているAPI連携
- プロバイダーごとに担当チームを振り分けるSIEMルール
- テスト用シークレットをコードに直接記載する運用
- Push protectionのバイパスを前提にした開発手順
- アラート通知を一部のSecret typeだけに限定している設定
今回の変更による新たな料金改定はない
今回のChangelogには、新たな料金や課金方式の変更は記載されていません。
公開リポジトリでは、Secret scanningを無料で利用できます。一方、Organization所有のPrivateまたはInternalリポジトリで利用する場合は、GitHub TeamまたはGitHub Enterprise CloudでGitHub Secret Protectionを有効にする必要があります。(GitHub Docs)
有料リポジトリのライセンス利用数は、GitHub Secret Protectionを有効にしたリポジトリへ直近90日以内にコミットがpushされた、ユニークなアクティブコミッターを基準に計算されます。今回のパターン追加自体で課金方式が変わるわけではありませんが、新しいリポジトリでSecret Protectionを有効化する場合は費用が増える可能性があります。(GitHub Docs)
Organization管理者は、次の画面から現在のリポジトリとアクティブコミッターに基づく費用を試算できます。
Security and quality → Assessments → Get started → Preview cost and enable Secret Protection
表示される金額は見積もりであり、実際の請求は契約形態と課金期間中の利用状況に基づきます。(GitHub Docs)
移行期限や対応期限は設定されていない
2026年6月17日の公式発表には、利用者が設定変更や移行を完了しなければならない期限は記載されていません。新しい検出パターンはすでに追加されているため、期限を待つのではなく、現在のアラートとPush protectionの設定を確認することが実務上の対応になります。(The GitHub Blog)
今回すぐに行うべきこと
まず、リポジトリの「Security and quality」からSecret scanningアラートを開き、新しく検出されたシークレットがないか確認してください。アラートが多い場合は、validity:activeを使って現在も利用可能な認証情報から対応します。
次に、「Settings」からSecret ProtectionとPush protectionの状態を確認します。Validity checksを利用できるプランでは有効化し、必要に応じてExtended metadataも設定しましょう。
シークレットが見つかった場合は、コードから削除するだけで終わらせず、発行元サービスで失効またはローテーションしてください。その後、利用先サービスの更新、不正利用の確認、アラートのクローズまで行うことが重要です。
コメント