GitHub Secret Scanningとは？機密情報をcommitしないために

Secret Scanningとは

Secret Scanningは、token、APIキー、passwordなど、秘密情報に見える文字列を検出するためのGitHubの安全機能です。

検出対象や提供条件は変わる可能性があるため、重要な判断ではGitHub公式情報も確認します。

このページでは、初心者が最初に理解したい考え方として、commitしない、push前に見る、検出されたら早めに対応する、の三つに分けます。

Push ProtectionとCode Scanningとの違い

Push Protectionは、pushしようとした時に秘密情報らしいものを止める方向の保護として理解すると入口として分かりやすいです。

Code Scanningは、コードの問題や脆弱性の検出に関係する領域です。Secret Scanningとは見ている対象が異なります。

どれも安全確認を助ける仕組みですが、絶対に事故が起きない保証ではありません。

commit前に見ること

GitHub Desktopやエディタで、差分にtoken、APIキー、password、秘密鍵、.env、設定ファイルが混ざっていないかを確認します。

不要なファイルはcommit対象から外し、必要な設定値はSecretsや環境変数など別の仕組みに分けます。

迷う場合は、その値が第三者に見えて困るか、権限操作につながるか、再発行が必要になるかで判断します。

検出された時の考え方

検出された時は、単に文字列を消すだけで終わらせず、その値が使われていた可能性を考えます。

必要に応じて無効化、再発行、共有範囲の確認、履歴に残った情報の扱いを整理します。

実際の事故対応手順や悪用方法を細かく書くのではなく、早めに関係者へ確認する、値を止める、同じ混入を防ぐ、という安全側の行動に寄せます。

機能に頼り切らない理由

Secret ScanningやPush Protectionは、危険に気づくための助けになります。ただし、すべての文字列、すべてのサービス、すべての設定ミスを必ず検出できると考えるのは避けます。

機能があるからcommitしてもよい、ではなく、commit前に混ぜない、push前に見直す、検出されたら止まる、という順番で考えると安全側に寄せやすくなります。

特に初心者は、警告が出なかったことを安全証明として扱いがちです。警告がなくても、公開して困る情報、権限操作につながる情報、個人や顧客に関わる情報は入れない方針にします。

private repositoryで油断しない

private repositoryは外部から見える範囲を狭めますが、共同作業者や連携アプリ、Actionsログ、将来の公開変更まで消してくれるわけではありません。

APIキー、token、password、秘密鍵、設定ファイルの中身は、privateでもリポジトリ本文に入れない方が安全です。値は別管理にし、コードには値を参照する形だけを残します。

チーム利用では、誰が見られるか、誰が権限を変えられるか、退職者や外部協力者の権限が残っていないかも確認します。Secret Scanningの前に、アクセス範囲の確認も必要です。

GitHub Desktopと組み合わせる時

GitHub Desktopでは、commit前に変更ファイルの一覧と差分を見られます。ここで秘密情報らしい文字列、設定ファイル、不要なバックアップが混ざっていないかを確認します。

SummaryやDescriptionにも、tokenやAPIキーの実値を書かないようにします。commit messageも履歴として残るため、本文と同じく公開される可能性を考えます。

push前には、どのbranchへ送るのか、リモートがpublicかprivateか、作業対象が正しいかを確認します。Secret Scanningだけでは、送信先の間違いまでは防げません。

検出後に整理する観点

検出されたら、まず慌てて公開の場に詳しい値を書かないことが大切です。値そのものを共有せず、どの種類の情報が混ざった可能性があるか、どのリポジトリか、いつのcommitかを整理します。

そのうえで、必要なら値の無効化や再発行、関係者への確認、権限の見直しを行います。履歴に残った可能性がある時は、単純な削除だけで十分かどうかを慎重に判断します。

同じことを繰り返さないために、.gitignore、Secrets、環境変数、commit前チェック、レビューの観点を見直します。検出は終点ではなく、運用を直すきっかけとして扱います。

commit前レビューに入れる観点

Secret Scanningの前に、人間が見る差分があります。GitHub Desktopなら、左側の変更ファイル一覧、中央の差分、commit messageの欄を順番に見ます。ブラウザならPull Requestやcommit画面で、追加された行と削除された行を落ち着いて確認します。

見る対象はコードだけではありません。README、手順メモ、設定サンプル、画像、CSV、バックアップファイル、ログの断片にも機密情報が混ざることがあります。初心者ほど、コード以外のファイルを見落としやすいので注意します。

確認で大事なのは、値そのものが書かれていないか、公開範囲に合わない情報がないか、後から第三者が読んで誤解しないかです。危険な情報を探すというより、公開してよい情報だけに整える作業として捉えると続けやすくなります。

関連ページへのつなぎ方

tokenの扱いに迷ったら、まずGitHub tokenページで認証情報の考え方を確認します。private repositoryに入れてよいか迷ったら、private repositoryやpublic/privateの違いのページへ戻ります。

Secretsの設定や機密情報の扱いに迷ったら、GitHub Secrets注意のページで、値を本文に出さない考え方を確認します。Secret Scanningは、その前提を補助する検出機能として位置づけます。

GitHub Desktopを使っている場合は、commit前確認のページへ進むと、差分、公開範囲、commit message、push前の確認を一続きで整理できます。安全系のページと実務系のページを行き来することで、知識だけで終わらない運用になります。

初心者向けの安全な言い換え

「漏れたらどう悪用されるか」を詳しく書くより、「第三者に見せない値」「権限操作につながる値」「再発行が必要になる値」と表現すると、危険な手順を書かずに注意を伝えられます。

「これで絶対安全」とは書かず、「確認の助けになる」「検出できる場合がある」「公式情報も確認する」といった言い方にします。GitHubの安全機能は強力ですが、使い方や条件によって結果が変わるためです。

「privateなら大丈夫」ではなく、「privateでも値は別管理」と書く方が安全です。この表現なら、初心者にも分かりやすく、過度に不安をあおらず、実務で守るべき線を示せます。

サイト運営での使いどころ

静的サイトや小さなWebサイトをGitHubで管理する場合、Secret Scanningの話は開発者だけのものではありません。問い合わせ先、広告タグ、計測タグ、FTP情報、外部サービスの設定など、サイト運営にも秘密情報に近いものがあります。

公開ページを増やす時は、本文、head、sitemap、関連リンクを見ます。特に安全系のページでは、読者がそのまま値を貼り付けたくなる表現を避け、確認する場所と保存しない方針を繰り返し示します。

Secret Scanningは、そうした運用の最後の網の一つとして捉えます。最初から混ぜない、commit前に見る、push前に止まる、公開後も確認する、という複数の小さな確認を重ねる方が安定します。

次に読むとよいページ

tokenの作成や扱いで迷う人は、GitHub tokenのページへ進むと、認証情報を作る前の確認を整理できます。private repositoryの扱いに迷う人は、private repositoryとpublic/privateの違いを先に読むと理解しやすくなります。

GitHub Desktopで作業している人は、commit前確認のページで差分の見方を確認します。Secret Scanningだけでなく、commit前の人間の目を入れることで、公開範囲や不要ファイルの混入にも気づきやすくなります。

Secretsと機密情報のページでは、APIキー、token、password、.envを本文に出さない考え方をまとめています。安全系ページは単独で読むより、関連ページをつないで見る方が実務に落とし込みやすくなります。

最初に確認する表

FAQ

関連ページ