Truffle Securityが実施した調査により、プラットフォームが機密シークレットの誤公開を防ぐためのツールを提供しているにもかかわらず、7月中にGitHubの公開リポジトリで543,699件の一意な認証情報が依然として有効かつ露出していたことが明らかになった。結果は、分岐したリポジトリのコピーを含む、224百万のリポジトリと580億件超のファイルに及ぶデータを分析したものだ。
問題は新しいシークレットだけに限られなかった。というのも、一意な認証情報は中央値で784日間、一般公開されたままだったからだ。稼働中のデータの約10%は6.3年以上前のものであり、調査で確認された最古の有効な認証情報は2009年にさかのぼる。
露出の範囲と傾向
調査で集計された認証情報は、110万件を超えるファイルとリポジトリに存在していた。分析は、大規模言語モデルの訓練用に作成されたデータセットに基づいており、2025年8月7日に完了したクロールを利用した。
Truffle Securityによると、この数は、8月にHugging Faceプラットフォームを調査した際に確認した件数の2倍を超えている。その際には、221,303件の稼働中の認証情報が見つかった。また、稼働中のシークレットの密度は、2015年のファイル100万件当たり3.72件から上昇し、2025年には11.62件のピークに達した。
Push Protectionが変えたもの
GitHubは2022年4月にAdvanced Securityユーザー向けにPush Protection機能を導入し、その後2023年5月に公開リポジトリで利用可能にした。さらに1年後、デフォルトで有効化した。この機能は、APIキーやアクセストークンなど、既知のパターンを対象に送信されるコードをスキャンし、検出時にはプッシュを阻止する。
しかし、この機能は、検出前に公開された認証情報を削除したり無効化したりするものではない。7月時点でも有効だった認証情報のうち、すべてのユーザーに対してPush Protectionが有効化された2024年2月以降に公開されたものは199,843件で、全体の約36.8%に当たる。また、稼働中の認証情報の51.8%は、デフォルトの保護機能が阻止しないカテゴリーに含まれていた。これには、データベース接続文字列やGoogle APIキーなどがある。
それでも、この機能は対象範囲内では効果的に見える。保護対象のカテゴリーにおける認証情報の露出率は、デフォルトで有効化された後に53%低下した。
なぜこのニュースが重要なのか
調査結果は、新しいシークレットのプッシュを阻止するだけではリスク全体に対処できないことを示している。シークレットはリポジトリの履歴や分岐したコピーに長期間残る可能性があり、対応の有効性も認証情報の種類や関連サービスによって異なる。
例えば、露出した101,886件のnpmトークンのうち、なお有効だったのは1件だけだった。一方、Google Cloudのサービスアカウントに関する126,963件の認証情報のうち、分析時点でも69,041件が有効だった。Truffle Securityは、露出した認証情報を直ちにローテーションし、リポジトリをクリーンアップし、変更履歴を確認し、アクティブなシークレットに自動的な有効期限を設定するよう推奨している。
この調査は、シークレットのうち実際に盗まれたり攻撃に使用されたりした割合を特定していない。そのため、測定しているのは悪用可能な露出の規模であり、確認された被害の規模ではない。この点は未解決の問題の一つであり、確認された有効な認証情報の数と混同すべきではない。