1. セキュリティ対策ラボ
  2. セキュリティニュース
  3. 個人情報漏洩のニュース
  4. Docker Hub イメージから1万以上の認証情報や認証キーなどが漏洩の可能性

Docker Hub イメージから1万以上の認証情報や認証キーなどが漏洩の可能性

セキュリティニュース

投稿日時: 更新日時:

Docker Hub イメージから1万以上の認証情報や認証キーなどが漏洩の可能性

セキュリティ企業 Flare の研究者 Assaf Morag 氏による調査で、わずか1か月間のスキャンだけで1万件超のDockerイメージから「生きた認証情報」を含むシークレットが検出されたことが明らかになりました。

調査の概要：1か月で1万超イメージからシークレット

Flare は2025年11月1日〜30日の1か月間、Docker Hubにアップロードされたコンテナイメージを対象に独自のスキャンを実施しました。
単なるメタデータではなく、イメージを実際に pull → 展開してファイルシステムを全スキャンした点が特徴です。

調査対象としたのは、代表的な15種類のシークレット（その後の検出結果から実際には数百〜数千種類に拡張され得ると分析）。

  • SDLC／ソース管理：GitHub Token、Bitbucket App Password、NPM Token 等

  • クラウド：AWS / GCP / Azure の認証情報

  • AI／LLM：OpenAI、Anthropic、Gemini、Hugging Face 等のAPIキー

  • その他：DB認証情報、暗号鍵、各種SaaSのAPIキー など

その結果、10,456件のコンテナイメージから1つ以上のシークレットが検出され、そのうち205の名前空間（Namespace）は深掘り調査の対象になりました。

205のうち101は企業と特定可能で、残りは個人アカウントと分類されています。企業は中小が多いものの、大企業やFortune 500企業、主要銀行も含まれていました。

さらに深刻なのは、42％のイメージが「5個以上」のシークレットを同時に抱えていたことです。

誰のアカウントから漏れていたのか

Flareの調査では、Docker Hubアカウントの持ち主は大きく3パターンに分類されています。

  1. 企業アカウントが自社の秘密をそのまま漏らしているケース

  2. 個人アカウントが個人の環境の秘密を漏らしているケース

  3. 個人アカウントが、所属企業や顧客企業の秘密を漏らしているケース（シャドーIT）

とくに3つ目がやっかいです。企業の公式レジストリやリポジトリはスキャナや監査の対象になっていても、社員やフリーランスの「個人Docker Hubアカウント」はほとんど可視化されていないからです。

レポートでは、いくつか象徴的な例が挙げられています。

  • AIカスタマイズを手掛ける企業が、GitHubのフル管理者権限（admin:org / admin:enterprise 含む）を持つトークンをDockerイメージ内にハードコード。
    これ1つでリポジトリ削除、Actions改ざん、パッケージ削除・差し替えなど、事実上あらゆる操作が可能だった。

  • 小規模企業向けにサイトやアプリを受託開発するフリーランス開発者の個人アカウントに、
    各顧客のAWSアカウント、S3バケット、PostgreSQL、アプリのAPIキー、Google Analyticsキー、OpenAIキーなどが一括で格納されたコンテナが多数存在。

  • ある主要銀行のチーフソフトウェアアーキテクトと思われる人物の個人Docker Hubからは、AI APIトークンを含む多数のイメージが公開状態で見つかり、銀行関連のイメージだけで430件以上が誰でも pull できる状態だった。

企業側から見れば、「公式には存在しないレジストリ」で自社の鍵が晒されているわけで、従来のログ監査やレジストリスキャンだけでは気づけません。

ハッキングではなく「認証情報」で侵入される

レポートでは、今回のDocker Hub調査に直接含まれないものの、同じ構図で発生した過去のインシデントもあわせて紹介しています。いずれも「秘密情報さえあれば、ゼロデイも高度なエクスプロイトも不要だったケースです。

NPMワーム「Shai-Hulud 2.0」

  • 正規のNPMパッケージに悪意あるスクリプトを仕込み、インストール時に開発者のトークンを盗む

  • GitHubやNPMの認証情報を使って、さらに別のパッケージやリポジトリに感染を拡大

  • 2025年版の2.0では、preinstallスクリプトやBunベースのペイロードなどに進化し、数百パッケージ・数万リポジトリ規模で横展開

GitHub Actions「tj-actions/changed-files」改ざん

  • 人気アクションがバックドア化され、WorkflowログにPATやレジストリトークンなどのCI/CD秘密情報を吐き出すように改変

  • きっかけは、SpotBugs のパーソナルアクセストークン漏えい

  • 攻撃者はその1つのトークンから権限昇格し、多数のリポジトリ・アクションへと供給網的に侵入

Microsoft Azure SASキー漏えい

  • GitHub上の公開リポジトリに、Microsoft内部のAIトレーニング用ストレージへフルアクセス可能なSASトークンが誤って含まれていた

  • 発見した者は、内部データセットの閲覧、ダウンロード、書き込みまで可能な状態

  • これを受け、Microsoftはストレージキーの管理・スキャン・ガバナンス体制を大幅に見直したとされる

ToyotaのAWSキー漏えい

  • AWSの認証情報がGitHub公開リポジトリにコミットされ、車両テレマティクスシステムにアクセス可能な状態が数年続いた

  • 200万台超の車両に関する位置情報や安全関連データに、長期間不正アクセスできてしまう構造だったと報じられている

これらに共通しているのは、「侵入経路の起点」がゼロデイや脆弱な暗号ではなく、開発者や組織自身がうっかり公開してしまった鍵やトークンだった点です。

なぜコンテナに.envなど秘密情報が入ってしまうのか

調査では、開発・DevOpsの現場でよく見られるパターンも具体的に検証されています。

典型例が「.envファイル」の取り扱いです。

  1. 開発者がローカル開発用に .env を作成し、DBパスワードやクラウドキー、APIトークンを羅列

  2. docker build 時に COPY . . のようにプロジェクト一式をコンテナにコピー

  3. 結果として .env ごとコンテナイメージに含まれ、そのままDocker Hubへ push

一見「プライベートレジストリだから大丈夫」と思いがちですが、その後設定変更や誤操作で公開範囲が変わったり、レジストリ自体が侵害されたりすれば、一気に外部に漏れることになります。

また、Dockerfileそのものにシークレットを書いてしまうケースも多く確認されました。
この場合、たとえコンテナ内には残らなくても、イメージマニフェストやDocker HubのWeb UI上からDockerfileが閲覧できてしまうため、結局インターネット全体に鍵を貼り出しているのと変わりません。

興味深いのは、「ミスに気づいた後の対応」です。
Flareの調査によると、約4分の1の開発者は1〜2日以内にコンテナやマニフェストからシークレットを削除していました。
しかしほとんどのケースで、元のキー自体は失効・ローテーションされておらず、そのまま有効だったとされています。

開発者の感覚としては「見えなくしたからOK」ですが、攻撃者側からすれば一度拾った鍵はずっと使える宝物です。公開から数分〜数時間で自動スキャナに拾われている可能性を考えれば、「削除＝安全」ではまったくありません。

防ぐにはどうすればよいか：組織としてやるべきこと

レポートでは、今回の結果を踏まえ、組織が取りうる実務的な対策も整理されています。要点をまとめると次の通りです。

コンテナイメージの中にシークレットを置かない

原則はシンプルで、「イメージの中に秘密情報を存在させない」ことです。

  • .env

  • 設定ファイル（config.json / YAML 等）

  • ソースコード中のハードコード

  • Dockerfile内のENVやRUN引数

これらにシークレットを書き込むのはやめ、実行時に環境変数やシークレットマネージャ経由で注入する設計に切り替える必要があります。

長生きする鍵をやめ、短命のセッションベース認証に移行する

AWS_SECRET_ACCESS_KEY や静的な GITHUB_TOKEN など、長期間有効な秘密情報はリスクの塊です。
可能な限り以下のような仕組みに置き換えるべきだとしています。

  • AWS STS + AssumeRole + MFA

  • Azure Managed Identity

  • GCP の Workload / Workforce Identity Federation

  • IDaaS（Okta / Auth0 等）の短命アクセストークン

「鍵が漏れても、すぐ期限切れになる」状態を標準にすることが重要です。

シークレット管理の一元化

各開発チームが好きな場所に鍵を置くのではなく、

  • AWS Secrets Manager

  • GCP Secret Manager

  • Azure Key Vault

  • HashiCorp Vault

  • 各種エンタープライズ向けVault製品

といった集中管理の仕組みにまとめ、発行・利用・ローテーションを統制することが推奨されています。

継続的なスキャンと「見つけたら即失効」

シークレットは、ソースコードだけでなく、

  • コンテナイメージ

  • パッケージレジストリ

  • CI/CDログ

  • S3バケットや各種ストレージ

  • コミット履歴やタグ

など、想像以上に広い場所に漏れます。
そのため、社内外のコード・レジストリ・コンテナを横断的にスキャンできる仕組みを整える必要があります。

そして何より大事なのは、「見つけた後」の動きです。

  • 鍵を即時失効させる

  • 新しい鍵を発行し、参照先を更新する

  • 古いセッションを無効化する

  • ログを確認し、不審なアクセスがなかったかを調査する

今回の調査で見えた「鍵だけ消して、キーは生かしたまま」という対応は、最悪のパターンだといえます。

シャドーIT（個人・外部アカウント）への可視性を持つ

公式のGitHubやDockerレジストリだけ見ていても不十分で、社員・フリーランスの個人アカウントに企業の秘密が載っていないかを監視する視点が求められます。

Flareは自社サービスの文脈で、外部レジストリやコード公開サイトを横断スキャンし、検出したAPIキー等から所属企業を逆引きして通知する、といったアプローチを紹介しています。
自社で同様の仕組みを用意できなくても、「個人アカウントに会社の鍵を置かない」ことを教育し、契約書やポリシーにも明記する必要があります。

開発者教育：便利さのための「ちょっとだけ」が命取りになる

最後に、開発者・DevOpsへの教育は欠かせません。

  • 「とりあえず .env に全部書いておく」

  • 「一旦ハードコードして動かしてから直すつもりだった」

  • 「個人アカウントのレジストリだから大丈夫だろう」

こうした判断が、数年後にニュースになるようなインシデントにつながりかねないことを、具体例とともに理解してもらう必要があります。

参照

Thousands of Exposed Secrets Found on Docker Hub, Putting Organizations at Risk

関連記事

AWSとGoogle CloudのCLIツールで情報漏洩の脆弱性 LeakyCLIAWSとGoogle CloudのCLIツールで情報漏洩の脆弱性 LeakyCLIが発生 GitHub Actionの「tj-actions/changed-files」の脆弱性がサプライチェーン攻撃に悪用される可能性(CVE-2025-30066)GitHub Actionの tj-actions/changed-files の脆弱性がサプライチェーン攻撃に悪用される可能性(CVE-2025-30066) Docker が重大な認証バイパスの脆弱性を修正(CVE-2024-41110)Docker が重大な認証バイパスの脆弱性を修正(CVE-2024-41110) Default ThumbnailAzure ネットワーク サービスタグで脆弱性が発生　悪用の可能性 Docker Desktopで危険な脆弱性(CVE-2024-8695 、CVE-2024-8696)Docker Desktopで危険な脆弱性(CVE-2024-8695 、CVE-2024-8696) GitHub Actionの「tj-actions/changed-files」が侵害される脆弱性(CVE-2025-30066)GitHub Actionの「tj-actions/changed-files」が侵害される脆弱性(CVE-2025-30066) オンラインコード/JSON 整形ツールに貼り付けた機密情報が世界に晒されている-秘密鍵や個人情報などが大量に漏洩オンラインコード/JSON 整形ツールに貼り付けた機密情報が世界に晒されている-秘密鍵や個人情報など大量に漏洩 Microsoft Azureの多要素認証(MFA)必須化、2025年10月から段階的に開始Microsoft Azureの多要素認証(MFA)必須化、2025年10月から段階的に開始 VS Codeの拡張機能を悪用する画面キャプチャ型 マルウェア「Bitcoin Black」「Codo AI」VS Codeの拡張機能を悪用する画面キャプチャ型 マルウェア「Bitcoin Black」「Codo AI」