Docker Hubの公開イメージ1万超でクラウド認証情報が漏洩——AI APIキーも多数、即応と恒久対策が必須です

今日の深掘りポイント

• 公開コンテナイメージ10,000件超から生のクラウド鍵・APIトークンが見つかり、100社超に及ぶ規模で露出しています。特にAIサービス向けAPIキーが約4,000件と多く、コスト被害と連鎖侵害の両面が現実化しやすい状況です。
• コンテナは「ビルドコンテキスト」と「レイヤ」の特性により、一度取り込んだ秘密が後工程で削除してもイメージ履歴に残留しがちです。コードリポジトリのSecret Scanningだけでは防げず、イメージそのもののスキャンとポリシーゲートが必要です。
• 個人のDocker Hubアカウント経由で企業情報が漏れる「シャドウレジストリ」問題が再燃しています。組織の公式レジストリ・命名空間以外を禁止し、外部公開にパイプラインの承認・署名を必須化するガバナンスが鍵です。
• 直近は72時間以内の一斉ローテーションと公開イメージの調査・無効化が最優先です。次いで、BuildKitのシークレットマウント、マルチステージビルド、.dockerignoreの徹底、短命認証の全面移行を整備すべきです。
• 攻撃側はOSINTでDocker Hubを横断スキャンし、漏洩鍵でクラウドに即時侵入する想定が妥当です。MITRE ATT&CKのValid AccountsやUnsecured Credentialsに該当する経路で、供給網・CI/CD・コストの三重の影響が起きやすいです。

はじめに

Docker Hub上の公開コンテナイメージから、実運用環境にアクセス可能なクラウド認証情報やAIサービスのAPIキーが多数見つかったと報じられています。Flareの分析によれば、少なくとも10,456件のイメージが1つ以上の機密情報を含み、100社超が影響を受ける可能性があるほか、AIモデルアクセス用トークンが約4,000件検出されたとされています。開発者の意図せぬ露出が増えており、ソフトウェア供給網リスクとして無視できない規模に達しています。The Registerの報道が一次情報の起点になっており、Flareの指摘として、生産系のクラウドやSaaSへの“実際に使える”資格情報が含まれていた点が重要です。

この種のインシデントは、単発の個別漏洩にとどまらず、組織のビルド・配布・運用の各レイヤを経由するサプライチェーン全体の露出に直結します。特にAI APIキーの流出は、機密性の毀損だけでなく、即時に課金型の被害に転化しやすいことが、過去のクラウド鍵漏洩とは質的に異なるリスクをもたらします。

深掘り詳細

事実（確認できる情報）

• Flareの分析として、Docker Hub上の10,456件の公開イメージから1つ以上の機密情報が検出され、100社超の影響を示唆、AIサービスAPIキーが約4,000件見つかったと報じられています。これらには生産環境のクラウドやSaaSにアクセスできる“生”の認証情報が含まれます。The Registerが報じています。
• コンテナビルドの仕組み上、ビルドコンテキストに含まれた.env、クラウドの認証ファイル、SSH秘密鍵などは、.dockerignoreで除外しない限りDockerデーモンに送られ、ADD/COPYでレイヤに取り込まれると、後のRUNで削除しても過去レイヤに履歴が残る特性があります。Dockerのドキュメントでもビルド時シークレットは専用メカニズムを使うことが推奨されています（BuildKitの--secret/secret mount）［参考: Docker Build secretsの公式ドキュメント］(https://docs.docker.com/build/building/secrets/)。
• 公開イメージのスキャンを自動化する手段は一般に普及しているものの、脆弱性スキャンに比べて“シークレット検出”は組織の導入率が相対的に遅れがちです。代表例としてTrivyはコンテナ内の秘密検出をサポートしており、CIに組み込むことができます（参考: Trivy）。

インサイト（編集部の視点）

• 供給網で最も見落とされやすい盲点は「イメージ層への秘密の焼き込み」です。VCSのSecret Scanningをクリアしても、ビルド工程でARG/ENVに鍵を流し込んだり、ビルドコンテキストに認証ファイルが残ったままADD/COPYしてしまえば、公開イメージ配布＝秘密の世界配布になります。後でrmしてもレイヤに痕跡が残るため、対策は“最初からイメージに入れない”以外にありません。
• 2025年の変化として、AI APIキーの普及が攻撃者に即時のマネタイズ手段を与えています。クラウド鍵は内在データやリソースへの侵害に直結しますが、AIキーはコスト爆発（大量推論）やブランド毀損（自組織名義の不正利用）を短時間で引き起こせます。プロバイダ側のIP制限やスコープ制限が十分でない場合、対処がローテーション依存になりやすく、運用の負担も跳ね上がります。
• メトリクス全体を見ると、緊急性と実行可能性が高く、確からしさも高水準です。現場は“今すぐ動ける手順”と“反復可能な恒久対策”を二段構えで設計するのが最も費用対効果が高いと判断します。具体的には72時間の初動（棚卸し・ローテーション・公開抑止）と、30日でのビルド/レジストリ・ガバナンスの再設計が現実的です。
• ガバナンス面では、個人のDocker Hubアカウントや個人命名空間の利用が露出の最短経路になりがちです。公式レジストリと命名空間を強制し、公開は署名付き・スキャン済み・承認済みだけに限定する“発信者管理”が、コードレビュー以上の効果を生みます。

脅威シナリオと影響

以下は報道と一般的な攻撃手口を踏まえた仮説に基づくシナリオです。MITRE ATT&CKの観点を併記します。

• シナリオ1：クラウド鍵からの即時侵入と持続化

  • 手口の流れ（仮説）:
    • OSINTでDocker Hubを横断検索し、イメージ内の認証情報を抽出（Reconnaissance: T1593 Search Open Websites/Domains, T1596 Search Open Technical Databases）です。
    • 漏洩したAWS/Azure/GCPのアクセスキーでログイン（Initial Access: T1078.004 Valid Accounts: Cloud Accounts）です。
    • 新規アクセスキーやロールの付与で持続化（Persistence: T1098 Account Manipulation）です。
    • ストレージやDBからのデータ収集（Collection: T1530 Data from Cloud Storage）と外部送信（Exfiltration: T1567 Exfiltration Over Web Service）です。
    • 不正マイニング・大規模ジョブ実行によるコスト加害（Impact: T1496 Resource Hijacking）です。
  • 影響: データ流出、基盤侵害、請求額の急増、監査・コンプライアンス違反です。

• シナリオ2：AI APIキーの悪用によるコスト・ブランド被害

  • 手口の流れ（仮説）:
    • 公開イメージからOpenAI/Anthropic等のAPIキーを収集し大量推論を実行（Impact: T1496 Resource Hijacking）です。
    • プロバイダの機能/設定によっては、当該キーがアクセス可能な“ファイル”や“ジョブ履歴”等のメタデータを参照し、二次情報を得る可能性があります（Discovery関連の一般技法）です。
  • 影響: 請求額の急増、レート制限による自社サービス停止、組織名義の不正利用による信用毀損です。

• シナリオ3：CI/CD・レジストリ資格情報を足場にした供給網攻撃

  • 手口の流れ（仮説）:
    • イメージに埋め込まれたアーティファクトレジストリやCIトークンを悪用し、内部レジストリへ不正プッシュ（Initial Access: T1078 Valid Accounts、Supply Chain Compromise: T1195）です。
    • 下流のサービスが“信頼済みベースイメージ”として継続的にPullし、改ざんされた依存イメージが広範に展開（Lateral Movement/Privilege Escalationの連鎖）です。
  • 影響: 広域なサプライチェーン汚染、顧客環境の横断的侵害、長期にわたるインシデントレスポンス負荷です。

総じて、Recon→Valid Accounts→Persistence→Collection/Exfiltrationという攻撃曲線が短いのが特徴です。公開イメージという“入り口の短さ”が、反応時間の短さ（ローテーションの遅れ＝侵入成立）に直結します。

セキュリティ担当者のアクション

初動と恒久対策を段階的に整理します。実環境の制約に合わせて優先順位を調整してください。

• 緊急（0–24時間）

  • 自社・グループの公開イメージ棚卸しです。Docker Hubの組織/個人命名空間を横断し、最新と過去タグ・削除済み含めて洗い出します。
  • 既知のパターン（クラウド鍵、SaaSトークン、SSH鍵、.env、.aws/credentials等）でイメージ内を秘密スキャンします。Trivy等のOSSでも即時に実施可能です（参考: Trivy）です。
  • 高リスク鍵（クラウドルート、CI/CD、レジストリ、データベース、AIプロダクション用）は使用停止・ローテーションを直ちに実施します。ログで異常使用があればブロックリスト化します。
  • Docker Hub側の公開可視性を一時的に制限し、必要に応じて該当イメージを非公開化/削除します。

• 迅速対処（24–72時間）

  • すべてのクラウド鍵に対し、権限最小化・条件付きアクセス（ソースIP/VPC/地域）・短命化（STS等）を適用します（参考: AWS STS）です。
  • AI APIキーは用途ごとに分離・ローテーションし、利用上限・予算アラート・異常使用検知を有効化します。可能な限りIP制限・スコープ制限を施します（ベンダにより制約がある点は留意します）。
  • SIEMで“新規に観測されたアクセスキーの使用元AS/国”、“AI APIの急増”を検知ルール化します。クラウド側でも異常なSTS/AssumeRole/AccessKey作成を監査します。

• 設計是正（1–2週間）

  • Build時の秘密ゼロ化です。Docker BuildKitのsecret mountを標準化し、DockerfileにARG/ENVで秘密を入れない方針を徹底します（参考: Docker Build secrets）です。
  • マルチステージビルドでビルド時依存（npm token等）をビルド用ステージに閉じ込め、最終イメージへ持ち込まない形に統一します。.dockerignoreで.env、鍵、Credentialsフォルダを必ず除外します（参考: .dockerignore）です。
  • 実行時の秘密はKMS/外部ボールトから注入します。KubernetesではSecret単体に依存せず、Secrets Store CSI Driverや外部シークレット連携を検討します（参考: Kubernetes Secrets、Secrets Store CSI Driver）です。
  • レジストリ・パイプラインのポリシーゲートです。公開は組織の公式命名空間のみ、ビルド時/プッシュ時の秘密スキャンと署名（例: cosign）を必須化し、未承認の公開をブロックします（参考: sigstore cosign）です。
  • 個人アカウントの使用禁止と例外承認プロセスを設け、シャドウIT化したレジストリ運用を根絶します。

• 継続運用（30日以降）

  • すべてのイメージに対し、定期的な脆弱性＋秘密スキャンを自動化し、結果をSBOM/アテステーションとして保存します。下流への配布条件（スキャン・署名・ポリシー適合）をSaaS/内部レジストリで強制します。
  • 外形監視として、ハニートークンを公開空間に配置し、OSINT収集者による不正使用を早期検知する仕組みを試験・導入します。
  • 監査と教育の定着です。開発者向けに「イメージ層に秘密を持ち込まない」「BuildKitの使い方」「.dockerignoreの最低限テンプレート」を標準として配布し、PR/パイプラインで機械的にチェックします。

• 現場Tips

  • イメージに秘密が含まれるかの一次確認にdocker historyや抽出後grepを活用します（参考: docker history）です。
  • 「後で削除」は通用しません。レイヤに刻まれます。マルチステージ＋secret mount以外の回避策は本質的解にはなりません。
  • KubernetesのSecretはデフォルトではbase64エンコードであり、十分な保護になりません。暗号化at-restや外部KMS連携を前提に設計します（参考: Kubernetes Secrets）です。

今回の事案は、公開コンテナという“流通媒体”に秘密が載ると瞬時に不可逆な露出になることを改めて示しました。初動での棚卸し・ローテーションに加え、「イメージに秘密を入れない設計」をビルド標準に組み込むことが、唯一の根本対策です。AI時代のコスト・信用リスクは上流で止めるしかありません。供給網の入口と出口、両端に堅いゲートを設けることが求められます。

参考情報

• The Register: Docker Hub leak exposes thousands of secrets in public images（Flareの分析を引用）: https://www.theregister.com/2025/12/11/docker_hub_secrets_leak/
• Docker Build secrets（BuildKitのシークレットマウント）: https://docs.docker.com/build/building/secrets/
• Kubernetes Secrets（暗号化と扱いの注意点）: https://kubernetes.io/docs/concepts/configuration/secret/
• Trivy（コンテナの秘密スキャン）: https://github.com/aquasecurity/trivy
• AWS STS（短命認証）: https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html
• sigstore cosign（コンテナ署名とアテステーション）: https://docs.sigstore.dev/cosign/overview/