GitHub Secret Scanningが大幅拡張、Push Protectionがデフォルトに

GitHubは2026年3月10日、シークレットスキャニング機能の大幅拡張を発表した。15プロバイダーから28個の新しいシークレット検出パターンを追加し、さらに39パターンでPush Protection（プッシュ保護）をデフォルト有効化するという、セキュリティ面で極めて大きなアップデートだ。対象にはVercel APIキー、Snowflake JWTトークン、Grafanaトークンなど、モダン開発スタックで頻繁に使用されるサービスが含まれる。GitHubによれば、2024年だけで3,900万件以上のシークレットがリポジトリから検出されており、クレデンシャル漏洩は依然として最も深刻なセキュリティ脅威の一つだ。

Secret ScanningとPush Protectionとは何か

Secret Scanning（シークレットスキャニング）

Secret Scanningは、GitHubリポジトリ内のコード・コミット履歴・Issue・PRコメントなどをスキャンし、APIキー・トークン・パスワードなどのクレデンシャル（シークレット）が含まれていないかを検出する機能だ。検出は正規表現パターンだけでなく、各プロバイダーと連携したパートナーパターンによって行われる。パートナーパターンでは、検出されたシークレットが実際に有効かどうかをプロバイダー側のAPIで検証し、有効であれば自動的に無効化（revoke）する仕組みも備えている。

Push Protection（プッシュ保護）

Push Protectionは、Secret Scanningをさらに一歩進めた予防的セキュリティ機能だ。従来のSecret Scanningは「プッシュされた後に検出・通知する」事後対応だったのに対し、Push Protectionはプッシュの時点でシークレットを検出し、そのプッシュ自体をブロックする。つまり、シークレットがリポジトリに到達する前に阻止するゲートキーパーとして機能する。

以下の図は、Push Protectionの動作フローを示しています。

開発者がシークレットを含むコミットをプッシュしようとすると、GitHubがリアルタイムでスキャンを実行し、検出した場合はエラーメッセージとともにプッシュを拒否する。開発者はシークレットをコードから削除し、コミットを修正してから再度プッシュする必要がある。

今回のアップデートの詳細

28個の新検出パターン

今回追加された28個の新パターンは、15のプロバイダーにまたがる。主要な対象は以下の通りだ。

• Snowflake: JWT（JSON Web Token）、PAT（Personal Access Token）の検出
• Vercel: APIキー、デプロイフックURL
• Grafana: サービスアカウントトークン、APIキー
• HashiCorp Vault: ルートトークン、サービストークン
• MongoDB: 接続文字列に含まれるクレデンシャル
• CircleCI / Travis CI: APIトークン

これにより、GitHubのSecret Scanningが対応する総パターン数は200以上に達した。

Push Protection のデフォルト有効化

最も影響の大きい変更は、39パターンでPush Protectionがデフォルト有効になったことだ。従来、Push Protectionはリポジトリ管理者が明示的にオプトインする必要があったが、今後は新規作成されるリポジトリ、および既存のパブリックリポジトリで自動的に有効化される。

これは「セキュリティはデフォルトでオンであるべき」というGitHubの方針転換を象徴している。開発者がPush Protectionを無効化するには、リポジトリ設定から明示的にオプトアウトする必要がある。

以下の図は、Secret Scanningが対応するプロバイダーのカテゴリ別一覧を示しています。

新たに追加されたプロバイダーはクラウド・インフラからSaaS、データベースまで幅広くカバーしており、モダンな開発環境で使われるサービスの大半が検出対象となっている。

クレデンシャル漏洩の深刻な統計データ

GitHubが公表しているデータは、シークレット漏洩の深刻さを物語っている。

• 2024年に検出されたシークレット数: 3,900万件以上
• 平均検出時間（Push Protection未使用時）: シークレットがリポジトリにプッシュされてから検出・対処されるまでに平均26日間が経過
• 漏洩後のインシデント発生率: 漏洩したクレデンシャルの約**12%**が実際の不正アクセスに使用
• 2024年のデータ漏洩コスト（IBM調査）: 1件あたり平均488万ドル（約7.3億円）

Push Protectionを使えば、そもそもシークレットがリポジトリに到達しないため、これらのリスクを根本的に排除できる。2025年にPush Protectionを有効化していたリポジトリでは、シークレット漏洩インシデントが95%削減されたとGitHubは報告している。

シークレット検出ツール比較

GitHub Secret Scanningは唯一のシークレット検出ツールではない。OSS やサードパーティのツールとの比較を確認しよう。

機能	GitHub Secret Scanning	GitLeaks	TruffleHog	1Password Secrets Automation
検出パターン数	200+	150+	800+	シークレット管理特化
Push Protection	デフォルト有効	pre-commit hookで対応	pre-commit hookで対応	N/A（管理側で対応）
プロバイダー連携	パートナーAPIで自動revoke	なし	一部対応	Vault連携
CI/CD統合	GitHub Actions標準	GitHub Actions/他CI	GitHub Actions/他CI	主要CI対応
料金	パブリックリポ無料	OSS（無料）	OSS+有料プラン	月$7.99〜（約1,200円〜）
コミット履歴スキャン	全履歴対応	全履歴対応	全履歴対応	N/A
リアルタイム検出	プッシュ時	コミット時	コミット時/CI時	利用時
セットアップ	設定不要（デフォルト有効）	ローカルインストール必要	ローカルインストール必要	アカウント登録必要

GitLeaksやTruffleHogはパターン数で優れている面もあるが、セットアップ不要でプロバイダーと直接連携してシークレットを自動無効化できるのはGitHub Secret Scanningの大きな強みだ。一方、シークレットそのものを安全に管理する観点では、1Password Secrets Automationのようなシークレット管理ツールとの併用が理想的である。

GitHubプラン別の機能差

Secret ScanningとPush Protectionの利用範囲はプランによって異なる。

機能	Free	Pro（月$4/約600円）	Team（月$4/user/約600円）	Enterprise + GHAS
パブリックリポSecret Scanning	有効	有効	有効	有効
パブリックリポPush Protection	デフォルト有効	デフォルト有効	デフォルト有効	デフォルト有効
プライベートリポSecret Scanning	パートナーパターンのみ	パートナーパターンのみ	パートナーパターンのみ	全パターン対応
プライベートリポPush Protection	パートナーパターンのみ	パートナーパターンのみ	パートナーパターンのみ	全パターン対応
カスタムパターン定義	不可	不可	不可	可能
シークレット有効性チェック	不可	不可	不可	可能
セキュリティダッシュボード	限定的	限定的	限定的	組織全体の統合ビュー

パブリックリポジトリでは全ユーザーが今回のアップデートの恩恵を受けられる。一方、プライベートリポジトリで全パターンの検出やカスタムパターンを利用するには、**GitHub Advanced Security（GHAS）**ライセンスが必要だ。GHASの料金は1コミッター当たり月$49（約7,350円）で、Enterprise Cloudプランへの追加オプションとなっている。

企業での設定方法・運用ベストプラクティス

基本設定

リポジトリ単位の設定は Settings > Code security and analysis から行える。Organization全体に一括適用する場合は、Organization設定の Code security > Global settings から有効化する。

推奨される運用フロー

1. Organization全体でPush Protectionを有効化: まず全リポジトリでPush Protectionをデフォルト有効にする
2. カスタムパターンの追加（GHASユーザー）: 社内独自のAPIキーやトークン形式がある場合、正規表現でカスタムパターンを定義する
3. バイパスポリシーの設定: Push Protectionをバイパス（回避）できるユーザーをセキュリティチームのみに限定する
4. Webhook通知の設定: シークレット検出時にSlackやPagerDutyに通知を飛ばし、即座にインシデント対応できる体制を整える
5. 定期的な全履歴スキャン: 過去のコミットにもシークレットが含まれている可能性があるため、定期的に全履歴スキャンを実行する

GitHub Copilotとの連携

GitHub Copilotを使ったコーディングでは、AIがシークレットをハードコードする提案を行うリスクもゼロではない。Push ProtectionはCopilotによるコード提案に対しても同様に機能するため、AIアシスタントとセキュリティ機能の二重防御が実現する。環境変数やシークレット管理ツールからの読み込みパターンをCopilotに学習させつつ、万が一の漏洩をPush Protectionで防ぐという運用が望ましい。

日本の開発チームへの影響

クレデンシャル漏洩事故の頻発

日本でもクレデンシャル漏洩によるセキュリティインシデントは頻発している。2024年には大手企業のAWSアクセスキーがGitHubパブリックリポジトリに誤ってプッシュされ、クラウドリソースが不正利用される事案が複数件報告された。IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2025」でも、「不注意による情報漏洩」が組織部門の上位にランクインしている。

日本企業への具体的メリット

今回のPush Protectionデフォルト化は、特に以下の日本企業にとって大きなメリットがある。

• スタートアップ・中小開発チーム: セキュリティ専任チームがいなくても、Push Protectionがデフォルトで有効なため最低限の防御が自動的に機能する
• オフショア・ニアショア開発: 海外パートナーとの共同開発でプライベートリポジトリを共有する際、Push Protectionが安全弁として機能する
• 個人開発者: OSSプロジェクトやポートフォリオをパブリックリポジトリに公開する際、うっかりシークレットを含めてしまうリスクが大幅に低減される

シークレット管理の推奨アプローチ

Push Protectionは「最後の砦」であり、根本的にはシークレットをコードに含めない運用が必要だ。1Passwordのようなパスワード・シークレット管理ツールを活用し、.envファイルやCI/CDのシークレット変数としてのみクレデンシャルを管理することが推奨される。GitHubのGITHUB_TOKENやActions Secretsを適切に使い分けることで、ハードコードのリスクを最小化できる。

まとめ：今すぐ実行すべき3つのアクション

GitHubのSecret Scanning拡張とPush Protectionのデフォルト化は、クレデンシャル漏洩対策の新たなスタンダードとなる。以下のステップで、今すぐセキュリティ体制を強化しよう。

1. Push Protectionの有効化を確認する: リポジトリの Settings > Code security and analysis を開き、Push Protectionが有効になっているか確認する。パブリックリポジトリでは既にデフォルト有効だが、既存のプライベートリポジトリは手動で有効化が必要な場合がある
2. 過去のコミット履歴をスキャンする: Push Protectionは新しいプッシュのみを対象とするため、過去のコミットにシークレットが残っている可能性がある。Secret Scanningのアラート一覧を確認し、検出されたシークレットを全てrevokeする
3. シークレット管理ツールを導入する: 1Password Secrets Automationや環境変数管理ツールを導入し、コードにシークレットをハードコードしない運用を徹底する。GitHub Copilotを使っている場合は、シークレット参照パターン（process.env.XXXなど）を優先的に提案するようプロンプトを工夫するとよい

クレデンシャル漏洩は「対岸の火事」ではない。Push Protectionがデフォルトで守ってくれる今こそ、シークレット管理の運用全体を見直す好機だ。