GitHubのPush Protectionでpushが止まったら、まず検出された文字列をチャット、Issue、ログへ貼らないでください。ブロックは、secret候補を含むcommitがpush対象にあることを示しますが、表示だけで「実際に使えるcredential」「すでに外部へ漏れた」とは確定しません。一方、Git上から文字列を消すだけで、実credentialが安全になったとも限りません。候補を値を露出させず確認し、実credentialまたは判断不能なら発行元で失効・ローテーションを検討し、commit履歴と影響範囲を調べます。誤検知や許可されたテスト値の場合だけ、権限ある手順で根拠を記録して処理してください。
目次
【最初に安全を確保する】
Push Protectionのエラーには、対象commitやfile path、検出種類が示される場合があります。値そのものをコピーせず、検出ID、commit hash、path、ブランチ、発生時刻を記録します。画面を共有する場合は、tokenらしき文字列や周辺の機密コードを伏せます。公開リポジトリへpushしようとしていたなら、回避を選ぶ前に作業を止め、リポジトリの可視性と過去に共有された範囲を確認します。
次にsecretの持ち主を特定します。環境変数、secret manager、provider dashboard、発行申請、担当チームなど、正規の保管元と照合します。GitHubに検出されていない通常のfixture値か、実際に発行されたcredentialかを区別します。正規の保管元にアクセスできず判断できない場合は、false positiveと決めず、credential管理者またはsecurity担当へ渡します。判定のためにtokenを外部のdecoderやオンライン検査サイトへ送らないでください。
【判断フロー】
-
実credentialまたは本物かもしれない：該当providerの管理者へ連絡し、利用ログと権限を確認します。公開済み、あるいは第三者が閲覧できる場所へ一度でも到達した可能性があるなら、GitHub上のblockだけに依存せず、発行元で失効・交換する必要があるかを優先して判断します。
-
テスト用のダミー値と確認できた：生成元、用途、値が実際に認証へ使えない根拠、保管元を記録します。誤検知を解除する場合は、repository/org policyと権限に従い、GitHubが示す許可またはbypassの経路を使います。
-
どちらか分からない：pushもbypassも保留し、secretの管理者に判定を依頼します。判断が遅れても、機密値を公開した状態で調査を続けないことが先です。
【どのcommitにあるかを切り分ける】
GitHubのエラー表示またはsecret-scanning alertで、検出対象のcommitが最新commitだけか、複数のcommitにまたがるかを確認します。最新commitの変更から誤って文字列を追加したなら、保護されたローカル作業でその変更を取り除き、差分と検出結果を再確認します。過去commitにも存在する場合、最新ファイルだけ修正してもpush対象の履歴にsecretが残ることがあります。どの範囲を書き換える必要があるかは、branchの共有状況、他メンバーの作業、remoteへすでにpushしたかによって異なります。
履歴を書き換える場合は、単独のローカルbranchか、他人が取得済みの共有branchかを先に確認します。共有履歴の書き換えは他メンバーのclone・branch・pull requestへ影響します。repository ownerと関係者に作業範囲、再取得手順、merge中の作業を確認し、承認された手順で実施してください。リポジトリ全体の履歴を書き換える必要があるケースを、単純な「ファイルを削除して再push」で済むものとして扱わないでください。
GitHubのCLI向け手順は、block messageで示された対象commitを調べ、secretを含むcommitから取り除く考え方を説明しています。検出パターンやUIは変わる可能性があるため、実際のエラーに表示されたfile/commitと現在のGitHub公式ヘルプを見ながら行います。ここではコマンドを一律にコピーするのでなく、対象範囲と共同作業への影響を先に確定します。誤ってmainや共有branchに対して強制更新を行うと、他の変更を失う危険があります。
【漏えい対応とGit修正は別作業】
検出されたものが実credentialなら、Gitの全履歴から削除できても、漏えい前の状態へ戻ったとは限りません。provider側でのrevoke/rotate要否、利用ログ、関連アカウント、権限範囲、同じ値の別利用箇所を確認します。既にremoteへpushした、pull requestやforkへ含まれた、ログやビルド成果物へ出た場合は、Git履歴の修正だけでなく関係者への連絡と再発行が必要かを判断します。値を再発行した後は、古いcredentialを無効化し、secret store、CI設定、実行環境、ローカル設定の更新対象を台帳で追います。
新しい値をコードやcommitへ貼り付けて「テスト」しないでください。GitHub Actionsのlog、cache、artifact、release、package、コメント等に複製がないか、必要な担当者がアクセス範囲を確認します。機密情報を不用意に再検索してログへ出すのではなく、secret scanning alert IDやcommit/pathなど秘匿値を含まない識別情報で追跡します。
【bypassは最後の例外】
Push Protectionのblockに対し、画面によっては理由を選ぶbypassや権限者へのrequestが表示されます。これは通常の修正を省略するためのボタンではありません。GitHub公式資料が示す権限・理由・承認フローに従い、テスト値・誤検知・許可された例外など、組織のpolicy上認められるケースだけ検討します。実credential、判断不能な値、公開可能性を排除できない値はbypassしません。申請時にも秘密値を説明欄へ書かず、alert識別子と非機密の理由で説明します。requestが拒否された場合、GitHubの公式案内に従い、commitからsecret候補を除く必要があります。
【再push前のチェック】
・候補の所有者と正規保管元を確認したか
・実credentialならprovider側の失効・交換要否を判断したか
・blockが示す全commitと対象pathを確認したか
・共有branch、PR、他メンバーへの履歴書換え影響を確認したか
・対象の値を最新ファイルだけでなくpush対象履歴から除いたか
・provider側の新しいsecretをコードへ埋め込まず、適切なsecret storeへ置いたか
・再スキャンで該当候補が残らないことを確認したか
・誤検知等なら権限あるbypass/approvalと理由記録があるか
一つでも不明なら、pushを急がずsecurity担当またはrepository ownerへ引き継ぎます。
【よくある失敗】
ファイルから行を削除してcommitを追加しただけで過去commitに値が残る、credentialをGitHub上で削除したので安全だと思う、blockを急いでbypassする、テストfixtureか確認せず実credentialを誤検知と扱う、共有branchの履歴を書き換えて他の作業を壊す、といった誤りがあります。修正後の最終状態だけでなく、push対象history、provider credentialの状態、関連artifactの露出可能性を個別に確認してください。
【incident記録テンプレート】
Repository / branch：＿＿
Alertまたはblock識別子：＿＿
Commit / path（secret valueは書かない）：＿＿
候補の分類：real / verified test fixture / unknown
Provider上の所有者・権限：＿＿
Remote push / PR / artifact exposure：yes / no / unknown
Provider側の失効・ローテーション判断と担当：＿＿
履歴修正の範囲・承認者・共同作業者への連絡：＿＿
再スキャン結果：＿＿
例外bypassを使う場合の承認・理由：＿＿
完了確認者と日時：＿＿
この票はsecretそのものを保存するためのものではありません。URL、commitメッセージ、ログの貼付にも値が含まれていないか確認してください。
【次の行動】
まずPush Protectionのblockに示されたcommit/pathを、値を表示せず記録します。正規のcredential保管元を管理する担当者と照合し、実credential・テスト値・unknownを分類してください。実credentialまたはunknownならprovider対応を優先し、履歴修正が共有branchへ及ぶ場合はownerと関係者の手順をそろえてから行います。false positive等の例外は、現在のGitHub policyと権限者の承認を確認できた場合に限ります。
【履歴と公開範囲を記録する】
調査結果は、credentialの値ではなく識別子と状態で残します。たとえば「secret-scanning alertの番号」「該当commit」「対象path」「push済みか」「pull request・fork・artifactに含まれた可能性」「provider側の失効担当」を記録します。誤検知なら、その値がテスト用に発行されたものか、認証に利用できないことを誰がどの保管元で確認したかを残します。リポジトリの公開範囲が変わった履歴も確認し、privateだった期間だけを理由に漏えいリスクなしと判断しないでください。remoteへ到達していた場合は、閲覧者の特定ができなくてもcredentialの露出可能性として扱い、provider側の利用ログと無効化判断を管理者へ渡します。履歴を書き換える前にはブランチ名、他者の作業、保護ルール、バックアップ要否を記録し、承認された操作範囲を越えないことが再発防止になります。
Sources（確認日：2026-10-15）
・GitHub Docs, Working with push protection from the command line: https://docs.github.com/en/code-security/how-tos/secure-your-secrets/work-with-leak-prevention/push-protection-on-the-command-line（新しいタブで開く）
・GitHub Docs, Working with push protection in the GitHub UI: https://docs.github.com/en/code-security/how-tos/secure-your-secrets/work-with-leak-prevention/push-protection-in-the-github-ui（新しいタブで開く）
・GitHub Docs, Bypass requests for push protection: https://docs.github.com/en/code-security/concepts/secret-security/bypass-requests（新しいタブで開く）
・Editorial Note: 実credentialの失効方法・利用ログは発行元サービスの公式手順で確認する。GitHubのblockはcredential提供元の漏えい対応を代替しない。共有履歴の書き換えはrepo ownerの管理手順と合意に従う。