新たな分析により、ライブAPIキー、クラウドアクセス・トークン、CI/CDシークレットなど、機密性の高い認証情報を漏えいしているDocker Hubのコンテナイメージが1万件以上あることが明らかになった。
この露出によって、攻撃者が脆弱性を悪用する必要すらなく、組織が直接侵害されるリスクにさらされる。
「Docker Hubでのシークレット露出は、今に始まったことではない。多くの脅威アクターがDocker Hubをはじめとするレジストリやコードリポジトリを積極的にスキャンしているため、露出したシークレットはすでに侵害されている可能性が高い」と、Flareのサイバーセキュリティ研究者Assaf Morag氏は述べた。
同氏はさらに、「認知が高まっていたにもかかわらず、2025年に露出した規模がこれほど大きかったことには驚いた。だからこそ、Docker Hubだけでなく、業界全体で認知を高め続けることが最も効果的なアプローチだと考えている」と付け加えた。
業界全体に広がるシークレット露出
今回の露出は、テクノロジー、金融、製造、コンサルティングなどの業界にまたがる100以上の組織と、Fortune 500企業1社に影響を及ぼしている。
多くの場合、露出した認証情報によって、本番環境のクラウド、非公開のGitHubリポジトリ、重要なCI/CDシステムへの管理者アクセスが可能になっていた。それにもかかわらず、影響を受けた企業は、これらのシークレットがDocker Hub上で公開アクセス可能になっていることを把握していなかった。
分析対象となったイメージの42％には、それぞれ5個以上のシークレットが含まれていた。つまり、1つのコンテナが侵害されるだけで、開発パイプライン全体やクラウドインフラが解除される可能性がある。
この調査では、漏えいしたAIモデルAPIキーが急増していることも明らかになった。露出したキーは約4,000個に上り、AIの導入が組織のセキュリティ確保を上回る速さで進んでいることを示している。
シークレットがコンテナイメージに入り込む仕組み
問題の根底にあるのは、現代のソフトウェア開発、自動化ツール、コンテナ化の実践が、シークレットに大きく依存していることだ。
これには、APIキー、クラウド認証情報、トークン、SSHキー、データベースのパスワード、モデルアクセス・トークンなどが含まれる。
研究者によると、開発者がシークレットを.envファイルや設定ディレクトリに保存したり、PythonやNode.jsのファイルにハードコードしたり、Dockerfileに直接埋め込んだりすることが多いため、シークレットがコンテナ内に入り込むケースが頻繁に発生していた。
その後、こうしたイメージが公開レジストリや個人レジストリ（請負業者が所有するアカウントを含む）にプッシュされ、機密性の高い認証情報が組織の監視の外に置かれ、意図せず露出する可能性が高まっていた。
Dockerのビルドプロセスでは、シークレットを含むファイルなど、プロジェクトのディレクトリ全体がコンテナイメージにコピーされていた。
こうしたイメージが公開Docker Hubリポジトリにプッシュされると、シークレットは誰でもアクセスできる状態になり、自動スキャンボットや脅威アクターによって即座に収集可能となる。
さらに懸念されるのは、露出が発覚した後にシークレットを削除した開発者がいた一方で、75％は基となるキーの失効やローテーションを行っていなかったことだ。つまり、目に見える漏えいを修正した後も、攻撃者は長期間にわたってキーを使い続けられた可能性がある。
実際のインシデントが示す露出シークレットの代償
この調査では、深刻度の高い事例がいくつか取り上げられている。
- 大手AIサービス企業は、コンテナイメージ内で完全な管理者権限を持つGitHubトークンを漏えいさせた。その結果、攻撃者はリポジトリの削除、CI/CDワークフローの改ざん、下流の顧客環境へのアクセスが可能になった。
- ある国立銀行のシニアアーキテクトは、数百件の公開イメージを含む個人のDocker Hubアカウントを運用していた。そのうち複数のイメージで、AI APIトークンや内部インフラのコンポーネントが露出していた。
- シャドーITも主要なテーマとして浮上した。請負業者や従業員が、企業のシークレットを含むコンテナを個人の名前空間に気付かないままアップロードし、組織による監視をすべて回避していた。
これらのインシデントは、攻撃者がシークレットの収集にますます注力する理由を示している。認証情報があれば、MFA、境界防御、ID保護を迂回できるからだ。
有効なキーがあれば、攻撃者はゼロデイを必要とせず、単にログインすればよい。
シークレット露出のリスクを低減するための対策
機密性の高い認証情報を保護するには、シークレットが現れる場所を減らし、その有効期間を制限し、開発ライフサイクル全体での管理と監視を強化する体系的なアプローチが必要だ。
- シークレットをコンテナに保存せず、.envファイル、設定ディレクトリ、アプリケーションコード、Dockerfileなどから確実に削除する。
- 短期間で期限切れになる、またはIDベースのアクセス方式を使用し、たとえばAWS STS、Azure Managed Identities、ワークロードIDフェデレーション、あるいはクラウドIAMロールに紐付けたサービスアカウントなどを利用する。
- すべての認証情報を管理対象のシークレット保管庫に集約し、すべてのキーやトークンに最小権限のスコープを適用する。
- 開発者のワークフローに自動シークレットスキャンを統合する。これには、コミット前チェック、プルリクエスト、CIパイプライン、コンテナイメージのスキャンを含める。
- 露出した認証情報は直ちに失効させ、ローテーションし、定期的なローテーションと衛生監査を実施する。
- 監視することで、請負業者や個人のレジストリを追跡してシャドーITを把握し、すべてのシークレットへのアクセスや異常な利用パターンについて、ログ記録とアラートを有効にする。
- 開発者に安全なシークレットの取り扱いを教育し、SDLCで信頼できないシークレットや不適切に扱われたシークレットが使われるのを防ぐため、ポリシー・アズ・コードとアプリケーション制御の対策を適用する。
これらの対策を組み合わせることで、組織は各環境におけるシークレット管理の信頼性とレジリエンスを高められる。
サプライチェーンにおけるシークレットのリスク拡大
今回の調査結果は、ソフトウェアサプライチェーン全体に広がる、より大きな課題を示している。組織が管理するシークレットの量は増加しており、一貫した安全対策がなければ、その一部が必然的に露出してしまう。
クラウドネイティブアーキテクチャが拡大し、AIを活用したサービスの相互接続が進むにつれ、流通する認証情報の数と、規律ある取り扱いの必要性は高まり続けている。
この傾向は、侵害されたGitHub Actionsワークフローや、Shai-Hulud NPM wormといった最近のインシデントとも一致する。これらは露出した開発者トークンを悪用し、大規模なエコシステム内を移動した。
高度に自動化された環境では、シークレットはシステムの運用に不可欠であり続ける一方、意図しないアクセスや悪用を防ぐための慎重なガバナンスも必要となる。
現代の開発チームにとって重要な焦点となっているのは、ソフトウェアサプライチェーンセキュリティが。