GitHubにうっかり公開された認証情報54万件以上が有効なまま放置されていることが判明

GitHubではソースコードをインターネット上で公開できますが、開発中の設定ファイルなどには外部サービスへ接続するためのAPIキーやパスワードが含まれる場合があります。認証情報をソースコードに書いたままGitHubへアップロードすると、第三者が認証情報を使ってクラウドサービスやデータベースへアクセスできる可能性が生じます。

Truffle Securityは大規模言語モデルの学習用データセット「The Stack v3」を使って、2億2455万3295件の公開GitHubリポジトリに含まれる約584億件のファイルを調査しました。The Stack v3の収集は2025年8月7日に終了しており、Truffle Securityは見つかった認証情報について2026年7月27日から28日に発行元サービスに対して認証を試み、実際に利用可能かどうかを検証しました。その結果、54万3699件が有効だったとのこと。同じ認証情報が複数のファイルやフォークに含まれるケースも数えると、認証情報の露出は110万3438件に上ります。

さらに、有効な認証情報が公開されてからの期間は中央値で784日で、全体の10％は6.3年以上前から公開されていました。最古の認証情報は2009年6月に更新されたファイルに含まれていたデータベース用の認証情報で、調査時にも利用可能だったとのことです。Truffle Securityは認証情報が有効であることから、該当するリポジトリ名を公開していません。

昔からGitHubでうっかり認証情報を公開してしまう事例が多発していたため、GitHubもさまざまな対策を行っています。代表的なのが「Push Protection」で、GitHubが対応している形式のAPIキーやアクセストークンを含むコードをアップロードしようとすると認証情報を検知して送信を止める機能です。公開リポジトリ向けのPush Protectionは2023年に利用可能となり、2024年2月から全ユーザーを対象にデフォルトで有効化されました。

下図では、Push Protectionがデフォルトで有効になった2024年2月29日以降に最終更新されたファイルをオレンジ色で示しています。Push Protectionがデフォルトで有効になった後に最終更新されたファイルからも、多数の有効な認証情報が見つかっています。

一方、Push Protectionの保護対象となる認証情報を詳しく調べると、デフォルト有効化の前後12カ月の比較でファイル100万件当たりの検出数が53％減少しています。GitHub側の検出・防止機能が強化された後も保護対象外の認証情報などが公開リポジトリに入り続けているというわけです。

今回確認された54万3699件のうち19万9843件はPush Protectionがデフォルトで有効になった2024年2月以降に公開されたものでした。また、有効な認証情報の51.8％はデータベースの接続文字列やGoogle APIキー、秘密鍵など、標準設定のPush Protectionではブロックされない種類だったとのこと。

さらにTruffle Securityが指摘しているのが、公開を防ぐ仕組みだけではすでに漏れた認証情報を無効化できないという問題です。GitHubのシークレットスキャンは対応する種類の漏えいした認証情報を検出できますが、有効な認証情報が見つかった場合には発行元で認証情報を失効させたり、新しい認証情報へ切り替えたりする作業が必要です。

サービスごとの差も大きく、GitHubに公開されたnpmトークン10万1886件のうち調査時まで有効だったものはわずか1件で、GitHubトークンも7万3048件のうち260件にとどまっています。一方、Google Cloudのサービスアカウント用認証情報は12万6963件のうち6万9041件が有効でした。Truffle Securityは、発行元が漏えいした認証情報を検知して自動的に失効させる仕組みを持つかどうかが大きな差につながっていると分析しています。

Truffle Securityは、公開リポジトリに認証情報を誤ってコミットした場合は検出の有無にかかわらず、漏えいしたものとして扱うべきだと注意を呼びかけています。誤ってコミットした場合は、まず認証情報を失効させて新しいものへ切り替え、その後にGitの履歴を整理するべきとのこと。また、Push Protectionがデフォルトで有効になる前に行われたコミットに関して、過去の履歴を自分でスキャンすることが推奨されています。できる限り有効期限付きの認証情報を利用することも重要だと述べています。