KICSの推進を捉える:何が起こったのか、そしてオープンで迅速な協力の必要性
ここ数週間、私たちは似た形のDocker Hubで2つのサプライチェーンの妥協を扱ってきました。最初はTrivy、今はCheckmarx KICSです。いずれの場合も、盗まれた出版社の認証情報を使って悪意のある画像を正当な出版フローに流しました。いずれの場合も、Dockerのインフラは侵害されていませんでした。そしてどちらの場合も、侵害されたタグを引き抜いたすべての人のソフトウェアサプライチェーンが一時的に露呈しました。
これは、KICSで何が起こったのか、影響を受けたユーザーが何をすべきか、そして防御者がどこに投資すべきかというパターンについての私たちの説明です。
何が起こったのか
4月22日、2026 UTC35 12頃に、有効なCheckmarxパブリッシャー認証情報を用いて脅威アクターがDocker Hubを認証し、悪意のあるイメージをcheckmarx/kicsリポジトリにプッシュしました。既存の5つのタグが悪意あるダイジェスト(latest、 v2.1.20、v2.1.20-debian,alpine、 debian)および2つの新しいタグ(v2.1.21、v2.1.21-debian)創造された。これらのイメージはCheckmarxのものではなく、攻撃者が管理するソースリポジトリから構築されました。
毒を含んだバイナリは正当なスキャン面を無傷に保ち、静かな脱出経路を追加した。スキャン出力は収集され、暗号化され、攻撃者が制御するインフラに送信されたaudit.checkmarx[.]cxユーザーエージェント KICS-Telemetry/2.0。KISはTerraform、CloudFormation、Kubernetesなどの設定ファイルをスキャンするため、その出力には秘密情報、認証情報、クラウドリソース名、内部トポロジーが常に表示されます。
影響を受けた悪意あるダイジェスト(プル履歴にあるこれらのどれかは悪意あるものとして扱うべきです):
For alpine, v2.1.20, v2.1.21 -> Index manifest digest: sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d
Image digest (amd64): sha256:d186161ae8e33cd7702dd2a6c0337deb14e2b178542d232129c0da64b1af06e4
Image digest (arm64): sha256:415610a42c5b51347709e315f5efb6fffa588b6ebc1b95b24abf28088347791b
For debian, v2.1.20-debian, v2.1.21-debian -> Index manifest digest: sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b
Image digest (amd64): sha256:a6871deb0480e1205c1daff10cedf4e60ad951605fd1a4efaca0a9c54d56d1cb
Image digest (arm64): sha256:ff7b0f114f87c67402dfc2459bb3d8954dd88e537b0e459482c04cffa26c1f07
For latest -> Index manifest digest: sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0
Image digest (amd64): sha256:26e8e9c5e53c972997a278ca6e12708b8788b70575ca013fd30bfda34ab5f48f
Image digest (arm64): sha256:7391b531a07fccbbeaf59a488e1376cfe5b27aef757430a36d6d3a087c610322
もしCIが露出ウィンドウ中に資格情報がスコープ内のリポジトリに対してKICSを実行した場合は、今すぐその資格情報をローテーションしてください。タグではなくダイジェストで再 checkmarx/kics 引き、CIをダイジェストにピン留めして、将来の上書きが静かに影響しないようにしてください。ローカルキャッシュ、CIランナー、プルスルーレジストリ、ミラーから悪意のあるダイジェストを一掃してください。クリーンプルではすでにキャッシュされているものは削除されません。audit.checkmarx[.]cxへの接続については、出口ログを確認してください。または、 KICS-Telemetry/2.0ユーザーエージェントは、インフラ上で漏洩が起きた強力な指標です。
影響を受けたダイジェストは無効化され、リポジトリは最後に確認された状態に復元され、checkmarx/kicsのプルは本日正当な3月32026画像を返します。悪意のある画像を配布するために使われた出版社アカウントは停止されており、テレメトリで検出された少数のユーザーに対して、侵害されたダイジェストを削除したことを通知しています。
Socketによるこの問題の技術分析は こちらです。彼らの投稿は、最近のVS Code拡張機能のリリースを含む、より広範なCheckmarxの妥協案についても取り上げており、開発者がそれらの拡張機能を使っているなら読む価値があります。
この侵害をどうやって発見したか
プッシュから約30分以内に、監視しているリポジトリに新しい画像が入ってレビューが始まりました。上流ソースとの照合で一致するリリースは見つかりませんでしたが、そのイメージはプッシュの前日に作成された別のソースリポジトリから作成されたものでした。それだけでリポジトリを隔離し、SocketとCheckmarxでフォレンジックを始めました。
防御は単一の信号ではなく相関関係にあります。このエピソードでは、上流のリリースがなく、出所も知らないもので、通常の出版動作と一致しないタイミングパターンの新しいタグを発見しました。偶然にこれらの信号を一緒に見たので、行動できる狭い時間帯を得てくれました。レイヤードディフェンスはプッシュとテイクダウンの間のウィンドウを短くするだけで、プッシュを防ぐわけではありません。
この種の攻撃の基準は崩壊しました
この事件、そしてそれ以前のトリヴィ事件で不快なのは、今の時代にこうした事件がほとんど必要としないという点です。IDE拡張機能の侵害から盗まれた資格情報、公開プロファイルから選ばれた標的、通常の公開フローを通った攻撃者、そして攻撃者はそのタグを引き出すすべての組織のソフトウェアサプライチェーンに潜入している。私たちの仮定では、この攻撃はゼロデイや新しいトレード技術、国家レベルの予算を必要としなかったということです。材料は盗まれた資格と時間であり、どちらも今は豊富にあります。
すべてのレジストリ、すべてのパッケージマネージャー、そして重要なパブリッシャーが標的となっており、Dockerも含めてです。これはCheckmarxの問題でもハブの問題でも、NPMの問題でもありません。それが新しい基準であり、デフォルトケースとして計画していない擁護者はすでに遅れをとっています。
私たちの生態系には二つの影響があります。
出版境界での認証情報の衛生管理は以前よりも重要になっています。単一のレジストリに限定された細かいトークン、短い認証情報の寿命、個人と出版社のアイデンティティの明確な分離。
そして、どの層もこれらすべてを捉えられないと。公開時の検証、出所、署名、レジストリ側の監視、深層パッケージ検査(Socketが依存関係の悪意ある行動を検出するために行うような)、実行時の離脱制御、クロスレジストリ信号の相関がそれぞれ作業を担います。なぜなら、どれか一方だけでは他のケースを見逃すからです。
構造的に難しい点についての注意
Docker Hardened Imagesカタログでは、画像はソースからDockerによって構築され、認証された出所と署名済みリリースがハード化されたビルドパイプラインを通じて生成されます。上記の攻撃のクラス、すなわち有効なパブリッシャー認証情報が上流ソースと異なるタグをプッシュする攻撃は、このように構築されたイメージに対して構造的に実行がはるかに困難です。外部の資格が入り込む代わりには存在しません。出所と署名が一致しなければ、画像は発送されません。DHIカタログは拡大しており、この層に投資しているのは、まさにこのブログで探ったシナリオと理由に基づいています。
誰も一人でこれを察知できるわけではありません
このインシデントが迅速に発見され、Socketが数時間以内に技術分析を作成でき、Checkmarxの対応が私たちの対応と並行して進められた理由は、3チームすべてがリアルタイムで信号とサンプルを共有していたからです。Trivyの回答も、攻撃者が管理するソースリポジトリに関するGitHubへの迅速な通知も同様でした。
これが生態系が減らすのではなく、もっと必要としている姿勢です。サプライチェーン攻撃者は数時間でレジストリ、IDEマーケットプレイス、ソースホスト、CIシステムを越えてルーティングしています。同じ境界線を越えて信号を共有しないディフェンダーは不利な立場から行動しています。登録簿間調整のための正式な基準はまだ形成中であり、いずれ重要になるでしょう。これまでのところ、窓口が短くなっているのは、チームがオープンな精神で取り組み、発見したことをリアルタイムで喜んで共有していたからです。
DockerはHubの多層防御に投資を続け、公開時の検証をカタログのより多くの部分に拡張し、パートナーのインシデントチャネル、ピアレジストリの調査、あるいはより持続的な調整フレームワークが形成される場でのシグナル共有に引き続き参加し続けます。
迅速かつ独立した分析をしてくれたSocketリサーチチームと、このプロジェクトに関して私たちと共に進んでくださったCheckmarxにも感謝します。
さらなる参考文献
ソケットブログ: https://socket.dev/blog/checkmarx-supply-chain-compromise
Docker Hub上のDockerハード化イメージ: https://hub.docker.com/hardened-images/catalog
