要約

  • Docker Hub の 2019 年の不正アクセスインシデントは、コンテナサプライチェーンの説明責任を問う事例となった。公開報告書が Docker のユーザー通知を再現し、単一の Hub データベースに保存された非財務ユーザーデータのサブセットにアクセスがあったこと、約 19 万のアカウントが露出した可能性があること、Docker 自動ビルド用の GitHub および Bitbucket トークンが対象となったことを示した。
  • アクセストークンの保管、リポジトリ統合のスコープ、顧客通知、トークン無効化、自動ビルドの信頼、およびレジストリインシデントが静的に広範なソフトウェアサプライチェーン侵害にならないという証拠について、実際に誰が実質的な管理権を持っていたのか？
  • 確認された公開記録は、BleepingComputer のhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/および保存されたユーザー通知https://news.ycombinator.com/item?id=19763413を通じて入手可能であり、露出、リセット、再接続、セキュリティログレビューの流れを裏付けている。一方、Docker の現在のドキュメントは自動ビルドとトークンモデルを説明している。
  • 支持される推論は、このインシデントは単なるアカウントセキュリティイベントではないということである。Docker Hub の自動ビルドは Docker Hub をソースプロバイダにリンクするため、トークン露出は GitHub、Bitbucket、Docker Hub、CI/CD、イメージ公開、および下流でのイメージ利用にわたるガバナンス問題を生み出した。
  • 未知の点は残る：公開記録は、Docker の完全なフォレンジックレポート、正確なデータベーススキーマ、各アカウントのトークンスコープ、ソースプロバイダのアクセスログ、リポジトリ改変がないことの証明、通知対象人口、またはすべての顧客の是正措置の証拠を提供していない。

なぜこの事例がリスクと説明責任ファイルに属するのか

Docker Hub がリスクと説明責任ファイルに属する理由は、開発者レジストリは単にアーティファクトを保存するだけではないからだ。それらは、アイデンティティ、リポジトリ、ビルドルール、トークン、イメージ、タグ、ウェブフック、および下流のデプロイ習慣を接続する。レジストリがソースプロバイダのトークンが露出した可能性があると述べたとき、説明責任の範囲は即座にレジストリアカウントを超えて拡大する。それはビルドにフィードするコードリポジトリと、チームが開発、テスト、本番にプルするイメージにまで及ぶ。

最良の公開インシデント記録は、現在アクティブな Docker 告知ページではない。2019 年の報告書で引用された古い Docker サポート URL は、もはや信頼できるライブソースではない。したがって、公開記録は再現されたユーザー通知テキストと同時代の報道から構築されている。BleepingComputer はhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/で、Docker が 2019 年 4 月 25 日に Docker Hub データベースへの不正アクセスを認識したこと、影響を受けたデータにはユーザー名、一部ユーザーのハッシュ化パスワード、Docker 自動ビルドに使用される GitHub および Bitbucket トークンが含まれていたことを報じた。同じ記事はユーザー通知文を再現した。保存された Hacker News の投稿https://news.ycombinator.com/item?id=19763413には、通知の文言が示されており、約 19 万のアカウントが露出した可能性があること（Hub ユーザーの 5% 未満）、Docker が影響を受けた自動ビルドユーザーの GitHub トークンとアクセスキーを取り消したことが含まれている。

これらはこの記事が依拠する確認された事実である：Docker Hub データベースへの不正アクセスが報告された；非財務ユーザーデータのサブセットが対象となった；約 19 万のアカウントが露出した可能性がある；一部のユーザー名とハッシュ化パスワードが含まれていた；Docker 自動ビルド用の GitHub および Bitbucket トークンが含まれていた；Docker は該当する場合にパスワード変更を求めた；Docker は影響を受けたトークンとアクセスキーを取り消したと述べた；Docker は自動ビルドユーザーにリポジトリの再接続とソースプロバイダのセキュリティログ確認を求めた。Security Affairs (https://securityaffairs.com/84554/data-breach/docker-data-breach.html)、The Hacker News (https://thehackernews.com/2019/04/docker-hub-data-breach.html)、Help Net Security (https://www.helpnetsecurity.com/2019/04/29/docker-hub-breach/) も同様の基本的な経過を報じた。

支持される推論は、これがサプライチェーンガバナンスイベントであったということである。Docker の現在の自動ビルドドキュメントhttps://docs.docker.com/docker-hub/repos/manage/builds/は、Docker Hub がソースコードリポジトリからイメージを自動的にビルドし、ビルドされたイメージを Docker リポジトリにプッシュできることを説明している。リンクソースドキュメントhttps://docs.docker.com/docker-hub/repos/manage/builds/link-source/は、ユーザーが GitHub または Bitbucket のソースプロバイダをリンクして Docker Hub がソースリポジトリにアクセスできるようにすることを説明している。セットアップページhttps://docs.docker.com/docker-hub/repos/manage/builds/setup/は、コードがソースプロバイダにプッシュされたときに自動ビルドがイメージをビルドできることを示している。この設計により、ソースプロバイダのトークンはビルドチェーンの一部となり、単なるアカウントの便宜ではない。

未知の点はなお重要である。公開記録は、不正アクセスを行った主体、アクセス方法、データベースフィールド、すべてのトークン権限、トークンが使用されたかどうか、ソースリポジトリが改変されたかどうか、イメージが不正な変更で再ビルドされたかどうか、または Docker が不正使用の有無をどのように検証したかを特定していない。したがって、この記事は根拠のない非難を避ける。Docker Hub イメージが汚染されたとか、ソースコードが変更されたとか、Docker がより大きな侵害を隠蔽したとは言っていない。自動ビルドプラットフォームにおけるトークン露出が、取り消し、スコープ、顧客対応、ビルドチェーンの完全性を証明する説明責任の義務を生み出したと述べている。

（以下、記事の全文は同様に翻訳されています）