GitHub 公開 リポジトリで54万3,699件の有効な認証情報が露出-中央値784日、最古は2009年から有効

セキュリティ企業Truffle Securityは2026年9月29日、公開GitHubリポジトリを対象とした大規模調査で、2026年7月時点でも認証に利用できる認証情報を543,699件確認したと公表しました。

調査対象は、大規模言語モデル（LLM）の学習用コードデータセット「The Stack v3」に収録された約2億2,455万件の公開GitHubリポジトリと、約584億7,000万ファイルです。

有効性を確認できた認証情報が公開状態にあった期間の中央値は784日でした。90パーセンタイルは6.3年、最も古い認証情報は2009年に更新されたファイルに含まれ、2026年7月時点でも利用可能だったとしています。

GitHubは公開リポジトリ向けにSecret scanningやPush protectionを提供しています。Truffle Securityの分析では、Push protectionの対象となる認証情報については公開コードへ到達する割合が導入前後で53％減少しており、漏えい防止策として一定の効果が確認されました。

一方、今回確認された有効な認証情報の51.8％は、データベース接続文字列やGoogle APIキー、秘密鍵など、GitHubのデフォルト設定ではPush protectionの対象にならない形式でした。

調査のサマリー

• Truffle Securityが224,553,295件の公開GitHubリポジトリを調査
• 対象ファイル数は58,467,468,698件
• 543,699件のユニークな認証情報が2026年7月27～28日時点でも有効
• 同一の認証情報がフォークや複数ファイルへコピーされたケースを含めると、露出箇所は1,103,438件
• 公開状態にあった期間の中央値は784日
• 90パーセンタイルは6.3年
• 最古の有効な認証情報は2009年に更新されたファイルに含まれていた
• Push protectionがデフォルト化された2024年2月以降に公開された有効な認証情報も199,843件確認
• 有効な認証情報の51.8％はデフォルトのPush protectionではブロックされない形式
• Push protection対象の認証情報は導入前後の比較で公開率が53％減少
• 調査結果から、認証情報が実際に攻撃者へ窃取・悪用された割合までは分からない

約2億2,455万リポジトリ、584億ファイルを調査

Truffle Securityが利用したのは、LLMの学習用データセットとして構築された「The Stack v3」です。

データセットのクロールは2025年8月7日に終了しており、調査対象にはGitHub上の公開リポジトリ224,553,295件、ファイル58,467,468,698件が含まれていました。

Truffle Securityは候補となる認証情報を検出した後、2026年7月27日と28日に発行元サービスへ確認し、その時点で実際に認証できるものだけを「有効」として集計しました。

その結果、543,699件のユニークな認証情報が利用可能でした。

同じ認証情報が複数のファイルやフォークへ複製されている場合は重複排除しており、元の露出箇所は1,103,438件に上ります。

有効な認証情報の51.8％はデフォルト設定ではブロック対象外

Truffle Securityによると、今回確認された有効な認証情報の51.8％は、GitHubのデフォルト設定ではPush protectionがブロックしない形式でした。

代表例は、

• データベース接続文字列
• 秘密鍵
• Google APIキー

です。

GitHubは認証情報の種類ごとに検出パターンを持っていますが、誤検知が多くなる形式や、公開利用と秘密情報の区別が難しい形式を一律にブロックすることはできません。

GitHubの公式ドキュメントでも、Push protectionは「対応するsecret」を対象としていることが明記されています。

組織独自の認証情報やデフォルト検出対象外の文字列については、カスタムパターンや追加のsecret scanning運用も検討する必要があります。

一度公開した認証情報は削除だけでは対応にならない

GitHubは公式ドキュメントで、漏えいしたsecretは直ちに侵害されたものとして扱い、無効化するよう案内しています。

コードから認証情報を削除して新しいcommitを作成したり、リポジトリを削除・再作成したりするだけでは、認証情報が悪用されるリスクをなくせません。

Gitの履歴やフォーク、コピーなどに認証情報が残っている可能性があるためです。

Truffle Securityも今回の調査結果から、

1. 公開された認証情報は最初にローテーション・失効する
2. その後、リポジトリと履歴をクリーンアップする
3. 過去のリポジトリ履歴もスキャンする
4. 有効期限のある短寿命な認証情報を優先する

という対応を挙げています。

有効な認証情報が公開された期間の中央値は784日

調査では、ファイルの最終更新日時を基に、認証情報が公開されていた期間を推定しています。

有効な認証情報の公開期間は中央値で784日でした。

さらに、

• 25％が4年以上前のファイル
• 90パーセンタイルが6.3年
• 2,636件が2015年より前のファイル
• 最古は2009年6月13日に更新されたファイル

という結果でした。

最古の認証情報はErlang Webサーバーの設定ファイルに含まれていたデータベース認証情報で、2026年7月時点でも利用可能でした。

Truffle Securityは、調査で確認したリポジトリ名を公開していません。認証情報が現在も利用できる状態であるためです。

Google Cloudサービスアカウントは6万9,041件が有効

認証情報の種類によって、有効なまま残る割合には大きな差がありました。

Truffle Securityが公開した主な結果は次の通りです。

GitHubやnpmのトークンは、有効なまま残った割合が非常に低い結果でした。

Truffle Securityは、発行元が公開されたトークンを検知して自動的に失効させる仕組みを持つかどうかが、この差に影響していると分析しています。

一方、データベース接続文字列などは、公開リポジトリ上で検知されてもサービス側が自動的に失効させる仕組みを持たないケースがあります。

3万1,374件のGemini APIキーも有効

Google APIキーでは、同じAIzaSy形式がGoogle MapsやFirebaseなど複数サービスで使われています。

公開を前提として利用されるGoogle APIキーもあるため、GitHubはGoogle APIキーを一律にPush protectionでブロックしていません。

Truffle Securityは今回の調査で、Google Gemini APIへの認証に利用できるキーを31,374件確認しています。

セキュリティ対策Labでは2026年3月、Google MapsやFirebase向けに公開されていたGoogle APIキーが、同一Google CloudプロジェクトでGemini APIを有効化した後、生成AIサービスへの認証に利用できるケースを取り上げています。

Google APIキーがGeminiの認証に転用されるリスク

APIキーが公開されているかだけでなく、そのキーが現在どのサービスや権限へ到達できるのかを定期的に確認する必要があります。

Push protection導入後も19万9,843件が有効な状態で公開

GitHubは2024年2月29日、ユーザー向けPush protectionをデフォルトで有効化しました。

Push protectionは、APIキーやアクセストークンなど対応している認証情報をコードへ含めた状態で公開リポジトリへpushしようとした際に検出し、pushをブロックする機能です。

今回の調査では、有効な認証情報543,699件のうち、

• 245,959件：Secret scanningが無料化される前
• 97,897件：Secret scanning無料化後、Push protectionデフォルト化前
• 199,843件：Push protectionデフォルト化後

のファイルに含まれていました。

ただし、この19万9,843件という数字だけで「Push protectionが機能していない」と判断することはできません。

Push protection対象の認証情報は公開率が53％減少

Truffle Securityは、Push protectionがブロックする形式と、デフォルトではブロックしない形式を分けて導入前後を比較しています。

その結果、Push protection対象となる認証情報は、導入前後12カ月の比較で公開される割合が53％減少しました。

一方、対象外の形式では減少率は7％でした。

GitHubやAWS、Slack、SendGrid、Google Cloudサービスアカウントなど、GitHubが認識してブロックできる認証情報では公開率が大きく低下しています。

Truffle SecurityもPush protectionについて、公開前に認証情報を止める対策として機能していると評価しています。

問題は、Push protectionだけではすべての認証情報をカバーできないことと、一度公開された認証情報を自動的に無効化する仕組みではないことです。

国内でもGitHub認証情報の流出を起点とした不正アクセス

今回のTruffle Securityの調査は、公開コード上の認証情報が長期間有効な状態で残っている実態を示したものです。

国内でも2026年、GitHub関連の認証情報流出を起点に実際の不正アクセスへ発展した事例が公表されています。

CAMPFIRE、個人開発サーバーへ置かれたGitHub認証情報が悪用

CAMPFIREは2026年6月、同社従業員が発行したGitHub認証情報が、従業員の個人開発サーバー上へ意図せずアップロードされ、第三者に不正利用されたことを公表しました。

攻撃者はGitHub上で閲覧できた情報から社内業務用クラウド環境の認証情報を探索・取得し、一部管理領域へ侵入しました。

漏えいのおそれがある個人情報の対象者は重複除外で最大225,846件です。

GitHub認証情報の流出からクラウド環境まで侵害されたCAMPFIREの事例

この事例では、1つのGitHub認証情報の流出が、別の認証情報の探索とクラウド環境への侵入につながっています。

イノベーションでは認証情報のハードコーディングが侵入経路に

株式会社イノベーションも2026年8月、GitHubへの不正アクセスについて、プログラムの設定ファイルへ外部サービスにアクセスする認証情報を直接記載していたことを原因として公表しました。

第三者がこの認証情報を取得・悪用し、GitHubリポジトリへ不正アクセスしました。

同社は最終的に62,689名分の個人情報漏えいを確認しています。

イノベーション、GitHubへの不正アクセスで個人情報漏えい

公開コードへの認証情報混入は、単なる「コード管理上のミス」で終わらず、権限次第では別システムへの侵入経路になります。

情報システム・開発部門が確認したい対応

今回の調査から、企業で確認したいポイントは「push時に止める仕組み」と「漏えい後に認証情報を無効化する仕組み」を分けて設計することです。

GitHubのPush protectionを有効化する

Push protectionは、対応するAPIキーやトークンを公開前に検出できます。

GitHubではユーザー向けPush protectionが公開リポジトリでデフォルト有効になっていますが、組織・リポジトリ単位の設定や、Secret Protectionの利用状況も確認します。

Secret scanningのアラートを「検出」で終了しない

secretを検出した後は、

• 認証情報を無効化
• 新しい認証情報を発行
• 旧認証情報の利用履歴を確認
• 不審なAPIアクセスを調査
• 関連する一時認証情報やセッションを失効
• リポジトリ履歴からsecretを除去

までを対応フローに含めます。

公開リポジトリ以外も対象にする

認証情報はGitHubの公開リポジトリだけで漏えいするとは限りません。

• プライベートリポジトリ
• CI/CDログ
• コンテナイメージ
• Wiki
• Issue・Pull Request
• Slack
• Jira
• 開発者の個人環境
• AI学習用データセット

などにも残る可能性があります。

CAMPFIREの事例では、起点となったGitHub認証情報は従業員の個人開発サーバーにアップロードされていました。

管理対象を「会社のGitHub Organization」だけに限定すると、こうした経路を見落とします。

長寿命の認証情報を減らす

Truffle Securityの調査では、10年以上前の認証情報が現在も有効なケースが確認されました。

可能な環境では、

• 有効期限付きトークン
• 短寿命クレデンシャル
• Workload Identity
• OIDC
• 最小権限
• 定期的なローテーション

へ移行し、漏えいした認証情報が長期間利用できる状態を減らします。

自社ドメイン・従業員に関連する公開secretを監視する

GitHubは2026年7月、Enterprise向けにPublic monitoringのプレビュー提供を開始しました。

Public monitoringは、企業が所有するリポジトリだけでなくGitHub.com上の公開領域を監視し、企業メンバーの活動や検証済みドメインなどを基に、企業に関連する可能性のあるsecretを検出します。

従業員が個人リポジトリやOSSプロジェクトへ誤って企業の認証情報をpushするケースを考慮すると、組織管理下のリポジトリだけでなくGitHub全体での露出監視も検討対象になります。

調査結果を見る際の注意点

今回の543,699件は「2026年7月時点のGitHub全体に存在したすべての有効認証情報」を示す数字ではありません。

調査対象はThe Stack v3に収録されたスナップショットで、クロールは2025年8月7日に終了しています。

また、データセットには各リポジトリのデフォルトブランチのみが保存され、commit履歴は含まれていません。

そのため、

• 2025年8月以降に新たに公開された認証情報
• 非デフォルトブランチだけに存在する認証情報
• クロール前に削除・force pushされた認証情報

などは今回の調査対象外です。

認証情報の「公開日」についても、Gitのcommit日時ではなく、データセットに記録されたファイルの最終更新日時を利用しています。

さらに、今回の調査で確認されたのは「認証情報が2026年7月時点で利用できた」という事実です。

その認証情報が実際に攻撃者へ窃取されたか、不正アクセスや情報漏えいに悪用されたかまでは今回の研究では明らかにされていません。

出典

• GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them. – Truffle Security
• Push protection – GitHub Docs
• Remediating a leaked secret in your repository – GitHub Docs
• Best practices for preventing data leaks in your organization – GitHub Docs
• Secret scanning public monitoring for enterprises – GitHub
• Push protection is enabled for free users on GitHub – GitHub
• 不正アクセス事案にかかる調査結果について – 株式会社CAMPFIRE
• GitHubへの不正アクセスに関する詳細調査の完了およびセキュリティ対策強化のお知らせ（確定報） – 株式会社イノベーション
• GitHubへの不正アクセスに関するお知らせ（確定報）の一部訂正について – 株式会社イノベーション