GitHubに公開された認証情報54万件が今も有効（2026年の調査）：削除ではなく失効が必要な理由と、開発者がやること

対象：GitHubなどの公開リポジトリにコードを置いている開発者と、APIを提供している事業者。本記事はセキュリティ企業が公開した調査の数字を、当サイトの言葉で整理し直したものです。他人の認証情報を探す方法は扱いません。

この調査は何か（GitHubの公式調査ではない）

2026年9月29日、シークレット検出ツールを販売するセキュリティ企業Truffle Securityが、公開リポジトリに残る認証情報の調査結果を公開しました。調査した側は検出ツールの提供元なので、結果を自社製品の宣伝にも使える立場にあります。本記事では数字をそのまま使い、解釈は当サイトの判断として書き分けます。

GitHubが何かを漏らしたわけではありません。認証情報をコードに書いて公開したのは、それぞれのリポジトリの持ち主です。GitHubの役割は、プッシュ保護（秘密を含むpushを止める機能）などの防止機能を提供することで、その対象には後で見るとおり限りがあります。

調べ方と、数字の読み方の注意

• 元データは、LLM（大規模言語モデル）の学習用に第三者が公開リポジトリを集めたデータセット「The Stack v3」です。収集は2025年8月7日に締め切られています。
• 調べたのは収集時点の既定ブランチ（main など）だけです。過去のコミット、別のブランチ、それ以前に消されたものは含まれません。GitHub上のすべての公開コードを調べたものではありません。
• 「有効」とは、見つけた認証情報を発行元のサービスに実際に問い合わせて、2026年7月27〜28日の時点で認証に通ったという意味です。その後に失効されたものもあり得ます。
• 漏れてからの期間は、認証情報を含むファイルの最終更新日から数えています。調査側は、実際より短めに出る測り方だと説明しています。
• 種類によっては一部の集計から外されています。Google APIキーはGeminiでしか有効性を確かめておらず、秘密鍵は使い先のサーバーがないと確かめられないため、種類ごとの残存率の集計には入っていません。

数字で見る：何が、どれだけ残っていたか

GitHubは2024年2月29日の週から、公開リポジトリへのpushに対するプッシュ保護を全利用者で既定で有効にし始めました。調査によると、有効だった543,699件のうち199,843件（36.8%）は、その日以降に入ったものです。

さらに、有効だった認証情報の51.8%は、接続文字列・Google APIキー・秘密鍵といった、プッシュ保護が既定では止めない種類でした。プッシュ保護の対象になっている種類は、既定化の前後12か月で比べると、100万ファイルあたりの漏れの数が約53%減っていました。対象外の種類は約7%の減少にとどまります。ただし調査側も、同じ時期にクラウド各社が短時間だけ有効な認証情報への移行を進めていたことなど、ほかの要因が混ざる可能性を認めています。

種類ごとに、どれだけ生き残っていたか

下の表は、調査が公開した件数から当サイトで割合を計算し直したものです。「見つかった数」は既定ブランチで見つかった認証情報の数、「有効だった数」はそのうち調査時点で認証に通った数です。

MongoDBは、調査に使った検出器が接続に成功したものしか記録しないため、割合が計算できず集計から外されています。有効な件数だけが報告されています。

なぜ種類によってこれほど差が出るのか

差を生んでいるのは、見つかりやすさよりも、見つかった後に誰かが止めるかどうかです。各社の公式ドキュメントで確認できた範囲では、次のようになっています。

GitHubの秘密スキャンのパートナープログラムは、公開リポジトリで見つかった認証情報を発行元に知らせる仕組みです。GitHubのドキュメントは、通知された秘密は公開済み・侵害済みとして扱うよう勧めつつ、どう実装するかは発行元に任せるとしています。失効、再発行、利用者への連絡のどれを選ぶかは発行元が決めます。

クラウドの2社は、完全な失効とは違う対応をとっています。

• AWS：公開された疑いのあるアクセスキーを持つIAMユーザーに、AWSが「AWSCompromisedKeyQuarantineV3」という管理ポリシーを付けます。これはインスタンスの起動やIAMの変更など一部の操作を拒否するもので、キーそのものを削除するものではありません。AWSはこのポリシーを外さず、作成されたサポートケースの指示に従うよう求めています。
• Google Cloud：2024年6月16日から、公開リポジトリなどで見つかったサービスアカウントキーを既定で自動的に無効化しています。組織ポリシーの制約 iam.serviceAccountKeyExposureResponse で、この動作をやめる（WAIT_FOR_ABUSE）こともできます。調査ではそれでも半数以上が有効でしたが、その理由は調査では示されていません。

漏らしたと気づいたときの手順

漏らさないための備え

プッシュ保護は役に立ちますが、それだけでは足りません。調査の数字が示すとおり、既定で止める種類以外は素通りし、利用者が理由を選んで通過させることもできます。次のものを組み合わせます。

• pre-commitでスキャンする：gitleaksなどの検出器で、pushより前の手元で止めます（→ gitleaksでコミット前に秘密を止める）。
• 古いリポジトリの履歴をスキャンする：プッシュ保護は既定化より前のコミットには効きません。放置しているリポジトリやアーカイブ済みのリポジトリも、一度は全履歴を検査します。
• 短時間だけ有効な認証情報を使う：GitHub ActionsからAWSやGoogle Cloudへは、OIDC（実行のたびに短時間だけ有効な認証情報を受け取る仕組み）で、長く有効なキーを置かずに接続できます。Hugging Faceも同じ方式の仕組みを用意しています。
• キーの範囲を絞る：読み取り専用、特定のAPIだけ、接続元IPやリファラーの制限、有効期限を設定します。漏れたときに困ることの範囲が小さくなります。
• データベースをインターネットに出さない：接続文字列が漏れても、外からつながらなければ使えません。表の中で最も生き残っていたのがDBの接続文字列でした。

秘密をコードに書かない基本は .envとAPIキーの超入門 に、Webサーバー上の置き忘れは 公開ディレクトリの棚卸し にまとめています。

APIを提供している事業者へ

表の上位と下位を分けたのは、発行元が漏れたキーを自動で止めるかどうかでした。利用者のキーを守る側として、次を検討する価値があります。

• GitHubの秘密スキャンのパートナープログラムに参加し、通知を受けたら有効なキーを失効させて利用者に知らせる
• キーに独自の接頭辞（例：サービス名で始まる形式）を付け、検出しやすくする
• 持ち主以外でも漏れたキーを報告・無効化できる窓口やAPIを用意する
• 有効期限付きのキーや、範囲を絞ったキーを既定にする

出典（公開記録）

本記事の数字は以下の公開情報にもとづきます。調査の文章や図は転載せず、件数だけを使って当サイトで整理し直しています。

• Truffle Security（シークレット検出ツールの提供元）による調査（2026年9月29日） — trufflesecurity.com
• 報道：BleepingComputer（2026年9月30日） ／ SecurityWeek（2026年10月1日） ／ GIGAZINE（2026年10月2日）
• GitHub：プッシュ保護の既定化（GitHub Blog） ／ プッシュ保護について ／ 対応パターン一覧 ／ パートナープログラム ／ トークンの有効期限と失効
• npm：npm Blog（2019年6月18日）
• Hugging Face：User access tokens（漏れたトークンの失効）
• AWS：AWSCompromisedKeyQuarantineV3
• Google Cloud：漏れたサービスアカウントキーの自動無効化（2024年5月16日） ／ サービスアカウントキー管理のベストプラクティス

次に読む

• 防ぐ：gitleaksでコミット前に秘密を止める ／ シークレット漏れ検出（貼り付けて検査）
• 基本：.env と APIキーは何が危なくて、どう守るのか ／ 「.env」とは
• 漏れた後の被害の例：AIで書いたコードからAPIキーが漏れ、不正課金された事例
• 開発者の認証情報を狙う攻撃：サプライチェーンワームからの守り方 ／ TanStack・Nx Console・GitHubの連鎖侵害（2026年5月）
• 鍵の権限を絞る：SSH鍵の最小権限