セキュリティ研究者は、GitHubの公開リポジトリに露出したにもかかわらず、現在も有効なままの固有の認証情報を543,699件特定しました。シークレットがソースコードに含まれてしまった後、それを無効化できていないという問題が根強く残っていることが浮き彫りになりました。
Securityawareness training
これらの認証情報は2026年7月の時点で有効であることが確認されており、その多くは何年も前から一般に閲覧可能な状態でした。
Truffle Securityの研究者らは、2億2,455万件の公開GitHubリポジトリと584億6,000万件超のファイルを含むデータセット「The Stack v3」を調査しました。このデータセットはAIモデルの学習用に収集されたデフォルトブランチのスナップショットで、クロールは2025年8月7日に終了しています。
研究チームは4,096個すべてのメタデータシャードをスキャンし、2026年7月27日から28日にかけて、シークレットの候補を発行元のサービスに対して検証しました。
分析の結果、1,103,438件の個別の露出にまたがる543,699件の有効な認証情報が見つかりました。認証情報が公開デフォルトブランチに残っていた期間の中央値は、784日だったと報告されています。
GitHub公開リポジトリで漏えいした有効な認証情報
データセット内で最も古い有効な認証情報は、2009年6月に最後に更新されたファイルに関連するものでした。16年以上たった今も有効だったことになります。研究者らは、2009年にさかのぼるFTPログイン情報、AWSキー、データベース認証情報、ダイナミックDNSの認証情報も、有効な状態で発見しています。
2015年より前に更新されたファイルに由来する、有効と確認された認証情報は合計2,636件でした。有効な認証情報全体の4分の1は公開から4年以上が経過しており、90パーセンタイルでは平均6.3年にわたって露出していました。
研究は、公開状態にあるシークレットは直ちに侵害されたものとみなすべきだと強調しています。リポジトリの最新版からシークレットを削除しただけでは無効にはなりません。認証情報がそのまま使える場合や、フォーク、コミット履歴、キャッシュされたコピー、クローンされたリポジトリに残っている場合は特にそうです。
GitHubは2023年2月に公開リポジトリ向けのシークレットスキャンアラートを無償化し、2024年2月にはこれらのリポジトリでプッシュ保護をデフォルトで有効にしました。プッシュ保護は、既知のシークレットパターンを含むコミットを、開発者が警告を意図的に回避しない限りブロックします。
研究者らによると、プッシュ保護がデフォルトになった後にコミットされた有効な認証情報は199,843件ありました。ただし、この対策が効果を発揮するのは、検出対象とする種類の認証情報に限られるようです。保護対象の認証情報ファミリーは導入後12カ月で約53%減少した一方、保護対象外の種類の減少幅は7%にとどまりました。
研究者らは、GitHubの保護対策は新たな漏えいの多くを防げるものの、対策の導入前に露出した認証情報には対処できないと結論づけています。
確認された有効な認証情報の半数超(51.8%)は、GitHubのデフォルトのプッシュ保護でブロックされない形式でした。データベース接続文字列、秘密鍵、Google APIキーなどがこれに該当します。
最も多かったのはGoogle Cloudのサービスアカウント認証情報で、有効なものが69,041件見つかりました。デフォルトでは保護対象外のMongoDB接続文字列も、有効なものが51,067件を占めました。研究者らはさらに、有効なGoogle APIキーを33,343件特定しています。このうち31,374件はGemini APIキーで、露出時期の中央値は2025年2月でした。
この区別が重要なのは、Google APIキーはサービスをまたいで同じプレフィックス(AIzaSy)を共有する場合があるためです。公開Webアプリケーション向けのキーもあれば、GeminiなどのクラウドサービスへのAPIで課金対象のアクセスを許可できるキーもあります。そのため、GitHubはこのパターンをデフォルトではブロックしていません。
調査によると、認証情報が生き残るかどうかは、シークレットの検出だけでなく、主に発行元による失効対応に左右されていました。失効の成果が最も高かったのはnpmトークンです。コミットされたnpmトークンは101,886件見つかりましたが、有効なままだったのは1件だけでした。GitHubトークンの生存率は0.36%、Hugging Faceトークンは0.05%でした。
これに対し、データベース接続文字列は高い割合で残存していました。露出したPostgreSQLのURIの88%、MySQLのURIの75%が、依然として有効だったといいます。Google Cloudのサービスアカウントキーの有効率は54%、SendGridキーは40%でした。
今回の結果は、組織が次の対応をとるべきだという考えを裏づけています。露出した認証情報は直ちにローテーションする。現在のブランチだけでなくリポジトリの履歴もスキャンする。短命で自動的に失効する認証情報を優先する。
GitHubのプッシュ保護は将来の露出を減らすうえで有効です。しかし、すでに公開コードに漏えいしたシークレットの影響を抑えるには、プロバイダーによる自動失効が引き続き不可欠です。
SOCのアラート調査を1件あたり21分短縮。即時のIOCコンテキストでSOCを強化し、迅速な対応を実現: SOCにTI Lookupを導入する
翻訳元: https://gbhackers.com/active-credentials-leaked-in-public-github-repos/
