最新の脅威動向から考える、コンテナサプライチェーンのリスクと対策

イベント登壇資料です。 2026/4/17 無償・OSSから始める、コンテナ脆弱性管理負荷を大幅に削減する新しいアプローチ
https://dockerjapan.connpass.com/event/388164/

Transcript

1. 最新の脅威動向から考える、 コンテナサプライチェーンのリスクと対策 @kyohmizu 2026/04/17 無償・OSSから始める、コンテナ脆弱性管理負荷を大幅に削減する新しいアプローチ
2. whoami Security Engineer at 3-shake inc. • Container/Kubernetes Security • AWS/Google Cloud Security • Security Operations & Technical Support for Blue Team • Cloud Native Security Assessment Others: • 3-shake SRE Tech Talk イベント運営 • 「コンテナセキュリティ」書籍監訳 Kyohei Mizumoto
3. 会社紹介 https://speakerdeck.com/3shake/3shake-sreake-deck
4. 本セッションについて 本セッションでは、最新の脅威動向をふまえ、コンテナシステムにおけるソフトウェアサプラ イチェーンのリスクと対策をご紹介します。
5. 目次 • コンテナシステムを取り巻く脅威動向 • コンテナのソフトウェアサプライチェーンとリスク • コンテナシステムの SCC セキュリティ対策
6. コンテナシステムを取り巻く脅威動向 01
7. クラウドネイティブ環境への攻撃キャンペーン（2025年12月〜） 脅威グループ TeamPCP による Docker / Kubernetes を標的とした攻撃キャンペーン • Azure, AWS を中心に60,000台以上のサーバーが侵害される • 独自スクリプトの他、 Sliver, Xmrig などの OSS を使用 • クリプトマイニング、ランサムウェア、データ窃取、スキャン基盤構築と目的が多様化 https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware ツール 役割 scanner.py Docker API / Ray Dashboard をスキャン、クリプトマイナー展開 kube.py K8s認証情報窃取、全ノードに特権Pod展開（ホストFS全体マウント） react.py React2Shell（CVE-2025-55182）の大規模悪用 pcpcat.py 広範囲IPスキャン、Base64ペイロード自動展開
8. ソフトウェアサプライチェーン攻撃の増加 2025年のSSC攻撃は前年比2倍以上に増加。被害額は $60B 以上 • OSSマルウェアの急増 ◦ 検出数は前年比 +73%。2025年だけで45万件以上の悪意あるパッケージを検出 • レジストリネイティブなワームの登場 ◦ npm ワーム Shai-Hulud が数百のパッケージと数万のリポジトリに感染を拡大 • メンテナーアカウントの侵害 ◦ chalk, debug 等のメンテナーがフィッシングで侵害され、悪意のあるバージョンが公開。 Dependabot の自動PRを通じて依存先のプロジェクトに伝播 • AI エコシステムの新たな脅威 ◦ Hugging Face 上の Pickle ファイルにマルウェアを隠蔽する攻撃や、悪意ある MCP サーバーの配布が発生 https://www.reversinglabs.com/sscs-report https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware https://bastion.tech/blog/2026-supply-chain-security-report/
9. セキュリティスキャナー Trivy の侵害（2026年3月） TeamPCP が Trivy のバイナリや Actions を侵害し、サプライチェーン攻撃に悪用 他にも KICS、LiteLLM、Telnyx などが連鎖的に侵害 https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack フェーズ 内容 バイナリ侵害 悪意あるバージョンがGitHub Releases, Docker Hub, GHCR, ECRに配布 Actions タグの改ざん trivy-action の76タグ中75を書き換え、ワークフロー変更なしで攻撃コード実行 認証情報窃取 Runnerメモリダンプ → SSH鍵、クラウド認証情報、K8s設定を収集・暗号化して送信 ワーム & ワイパー 窃取したnpmトークンで "CanisterWorm" を伝播。K8sでは特権DaemonSetで全ノード に展開
10. npm パッケージの侵害: Shai-Hulud（2025年9月〜） パッケージレジストリを介して自己感染する初のワーム型マルウェア • 窃取した認証情報で次々と他のパッケージを侵害し、レジストリ経由で感染が拡大 • V1 は postinstall、V2 以降は preinstall で実行 • 約 25,000 の悪意あるGitHubリポジトリを作成 https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack 発生時期 概要 2025年9月 数百の npm パッケージを侵害 2025年11月（2.0） @zapier, PostHog, CrowdStrike 等の著名パッケージに感染拡大 2025年12月（3.0） 難読化・信頼性を強化した亜種が出現。現在も活動中
11. Axios パッケージの侵害（2026年3月） 週間1億DL超のHTTPクライアントライブラリに悪意あるバージョンが公開 経緯 • 2026年3月31日、リードメンテナーの PC がソーシャルエンジニアリング + RAT で侵害 • 窃取した npm 認証情報を使い、npm CLI から直接悪意あるバージョンを公開（ CI/CD をバイパ ス） • postinstall スクリプトに隠された依存パッケージが RATをドロップ 影響 • macOS / Windows / Linux のクロスプラットフォームで動作 • npm install を実行しただけで RAT に感染 • 正規の Axios と同じパッケージ名・レジストリから配布されたため、検知が困難 https://www.sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan
12. React2Shell の悪用（2025年12月） React Server Components の深刻な脆弱性（CVE-2025-55182） • 認証なしのRCEの脆弱性で、CVSSスコアは 10.0 • Kubernetes においても、クラスタ上の Next.js アプリケーションが標的となる • 公開当時、クラウド環境の 39% が脆弱なインスタンスを保有 • 公開数時間後には中国系 APTが悪用開始 • TeamPCP の攻撃キャンペーンにも利用される https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182
13. CI/CD パイプラインへの攻撃 GitHub Actions がサプライチェーン攻撃の標的に tj-actions/changed-files（CVE-2025-30066） — 2025年3月 • 23,000以上のリポジトリで利用される GitHub Action • 攻撃者がPATを侵害し、Runnerメモリからシークレットを抽出してログに出力 • 全バージョンタグが悪意あるコミットに書き換えられる hackerbot-claw — 2026年2月 • 自律型ボットが安全でない GitHub Actions設定を悪用 • pull_request_target や未サニタイズ入力など、 Actionsの設定不備を悪用した RCE GitHub Actionsをコミットハッシュで固定している組織はわずか 4%（71％は固定なし） https://www.datadoghq.com/state-of-devsecops/ https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation
14. Kubernetes コンポーネントの脆弱性 runc の脆弱性（2025年11月） • Docker, containerd, Kubernetes, 全主要クラウドのマネージド Kubernetes に影響 • エスケープ成功後、ノードの kubelet を掌握しクラスタ全体の侵害に発展する可能性 nodes/proxy の問題（2026年1月） • 監視ツール（Datadog、Cilium 等）が広くこの権限を付与 • 監査ログに記録されず検知が困難。 CVE は採番されず仕様扱い https://www.cncf.io/blog/2025/11/28/runc-container-breakout-vulnerabilities-a-technical-overview/ https://grahamhelton.com/blog/nodes-proxy-rce CVE コンポーネント CVSS 概要 CVE-2025-31133 runc 7.3 maskedPaths のレースコンディションによるコンテナエスケープ CVE-2025-52565 runc 7.3 /dev/console マウント競合によるホストパスへの書き込み CVE-2025-52881 runc 7.3 LSM バイパスによるホストクラッシュまたはコンテナエスケープ - kubelet - nodes/proxy GET ですべての Pod に RCE
15. Kubernetes エコシステムの脆弱性 CVE 対象 CVSS 公開 概要 CVE-2025-593 60 Chaos Mesh 9.8 2025/9 コマンドインジェクションにより任意の Pod でコード実行が可能 CVE-2026-220 39 Kyverno 9.9 2026/2 ポリシーエンジンの認可バイパスにより Namespace 分離が破 壊され、クロス Namespace の読み書きが可能 CVE-2026-278 76 Grafana 9.1 2026/3 SQL Expressions を経由した RCE。Viewer 権限以上で悪用 可能
16. コンテナのソフトウェアサプライチェーンとリスク 02
17. ソフトウェアサプライチェーン（SCC）とは ソフトウェアの開発と提供に関わるすべてのコード、人、システム、プロセス • 作成するコードとその依存関係 • 開発、ビルド、パッケージ化、インストール、実行に使用するソフトウェア • アクセス制御、テスト、レビュー、監視に関するプロセスとポリシー • 依存関係の開発、ビルド、保管、実行を担うシステム サプライチェーン攻撃の特徴 • 攻撃側: 1つの侵害から多数の組織に影響。セキュリティレベルの高い組織にも侵入可能 • 防御側: アタックサーフェスが多岐にわたり、網羅的な対策が困難 https://cloud.google.com/software-supply-chain-security/docs/overview
18. コンテナシステムの SCC アーティファクト アーティファクト：データの集合、成果物 • アプリケーションのソースコード • アプリケーションの依存関係（言語のフレームワークやライブラリ） • アプリケーションバイナリ • Dockerfile • コンテナイメージ • コンテナの依存関係（ベースイメージ、追加するパッケージ） • インフラのソースコード（ IaC: Kubernetes Manifests, Helm Charts） • CI/CD パイプラインの設定やサードパーティプラグイン
19. コンテナシステムの SCC（図）
20. SSC における主な攻撃手法 攻撃手法 概要 代表的事例 タイポスクワッティング 正規パッケージ名に類似した悪意あるパッケー ジを公開 typescript-eslint や @types/node を騙るマルウェア 依存関係の混同（Dependency Confusion） 内部パッケージと同名の悪意ある公開パッケー ジをインストールさせる 企業内部パッケージ名を狙った攻 撃 アカウント乗っ取り メンテナーの認証情報を窃取し正規パッケージ にマルウェア注入 Axios, Gluestack, chalk/debug タグポイズニング バージョンタグを悪意あるコミットに書き換え Trivy Action, tj-actions ビルドシステム侵害 CI/CDパイプラインを侵害しビルド成果物にマル ウェア注入 Nx ビルドシステム レジストリ汚染 公開レジストリに悪意あるコンテナイメージを配 置 Docker Hub上の悪意あるイメー ジ
21. コンテナ環境での攻撃チェーンの実例 TeamPCP/Trivy 侵害で観測された多段階攻撃 1. CI/CDパイプライン侵害（Trivy Action タグポイズニング） 2. クレデンシャル窃取（Runner メモリダンプ → K8s設定、クラウド認証情報） 3. Kubernetes 環境検出（proxy.sh → K8s環境かどうか判定） 4. 専用ペイロード投下（kube.py → クラスタ認証情報収集、リソース探索） 5. 特権 DaemonSet 展開（コントロールプレーン含む全ノード） 6. 破壊 or 永続化（ワイパーによるクラスタ破壊 / バックドアの永続化） https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/ https://www.aikido.dev/blog/teampcp-stage-payload-canisterworm-iran
22. サプライチェーン攻撃と境界防御の無力化 サプライチェーン攻撃はネットワーク境界を迂回して内部に到達 • 依存パッケージやCI/CDパイプラインを経由して、開発端末・ CIがマルウェアに感染 • 正規のビルドパイプラインから、バックドア入りのコンテナイメージが配布される 内部のセキュリティ不備が被害を拡大 • 外部公開システムと比べ、内部システムのセキュリティ対策は優先度が低くなりやすい • RBAC の設定不備や過剰な権限付与が横移動、権限昇格の起点に • サービスアカウントトークンの窃取による横移動、クラウドアカウントへの到達
23. 悪性コードの混入と脆弱性の違い 悪性コードの混入と従来の脆弱性は性質が異なり、求められる対策も異なる 脆弱性（CVE） 悪性コード混入 性質 意図しないバグ・設計ミス 攻撃目的で意図的に埋め込まれたコード 検知 脆弱性スキャナーで検知可能 基本的にCVEは採番されず、スキャナーでは検知できない 発動条件 攻撃者が外部から脆弱性を悪用 インストール時に自動実行される 影響範囲 本番環境（デプロイ後） 開発環境・CI/CD環境でも即座に感染
24. OSS のセキュリティ体制のリスク 利用している OSS に、脆弱性やインシデント発生時に適切に対応できる体制があるか XZ Utils バックドアの事例 • 実質的に一人のメンテナーが維持するプロジェクトだった • メンテナーの燃え尽きに付け込み、攻撃者が 2年以上かけて共同メンテナーの地位を獲得 • コードレビューや後継者計画の不在が攻撃を許した 利用する OSS のセキュリティ体制を事前に評価することが重要 OpenSSF Scorecard 等のツールで自動評価が可能 https://www.cisa.gov/news-events/news/lessons-xz-utils-achieving-more-sustainable-open-source-ecosystem
25. 攻撃速度の加速と検知の限界 攻撃の自動化やツールの成熟により、脆弱性の悪用から侵入後の被害発生まで速度が劇的 に短縮 • 脆弱性の悪用速度 ◦ 2025年前半、悪用された脆弱性の 32% が公開から24時間以内に悪用 • 侵入からインパクトまでの速度 ◦ 初期アクセスから横移動までの平均時間は 29分（前年比65%高速化）、最速は27秒 検知してから対応するサイクルでは、攻撃速度に追いつくことが困難 攻撃が成立する条件を事前に排除する予防型の対策がより重要に https://www.vulncheck.com/blog/state-of-exploitation-1h-2025/ https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
26. コンテナシステムの SCC セキュリティ対策 03
27. セキュリティ対策の方針 予防型セキュリティ対策の重要性 — 攻撃が成立する条件を事前に排除する 開発ライフサイクル全体のセキュリティ • 開発端末、CI/CD、レジストリ、本番環境などの各段階でセキュリティ対策を実施 • 内部ネットワークにおいても十分なセキュリティ対策を検討 予防策 効果 OSS のセキュリティ体制の評価 リスクのある OSS の利用を事前に回避 依存関係の削減・安全なイメージの利用 攻撃対象となるコンポーネントを構造的に削減 ポリシーエンジン（OPA Gatekeeprt 等） ポリシー違反をデプロイ前にブロック 悪意あるパッケージの混入防止 ハッシュ固定、パッケージ検証、コード解析等 イメージ署名 / SLSA Provenance 改ざんされた成果物のデプロイを防止 CSPM / KSPM クラウドや Kubernetes の設定不備を継続的に検出・是正
28. OpenSSF Scorecard による OSS の評価 OpenSSF Scorecard — OSSプロジェクトのセキュリティ健全性を自動評価 100万以上のOSSプロジェクトに対して、 0〜10のスコアを自動算出 https://github.com/ossf/scorecard チェック項目 評価内容 Code-Review PRマージ前のコードレビューが必須か Branch-Protection デフォルト・リリースブランチに保護設定があるか Maintained プロジェクトが活発にメンテナンスされているか Vulnerabilities 未修正の脆弱性がないか Dependency-Update-Tool Dependabot等による依存関係の自動更新があるか Fuzzing ファジングテストが実施されているか SAST 静的解析ツールが使用されているか Signed-Releases リリースが署名されているか
29. OWASP Top 10 OSS リスク OWASP Top 10 Open Source Software Risks — OSS固有のリスクを体系化 評価ポイント • メンテナーの人数と活動頻度（単一メンテナーのリスク） • コードレビュー・ブランチ保護の有無 • 脆弱性報告への対応速度 • ガバナンス体制（組織管理 vs 個人管理） https://owasp.org/www-project-open-source-software-top-10/ リスク 概要 OSS-RISK-4 Unmaintained Software 開発が停止し、パッチが提供されない OSS-RISK-8 Immature Software 標準的なバージョニング、テスト、レビューが未整備 OSS-RISK-6 Untracked Dependencies 推移的依存関係が把握されていない OSS-RISK-9 Unapproved Changes 不正なコード変更の検知メカニズムがない
30. 悪意のあるパッケージの混入防止 依存パッケージを通じた悪性コードの混入を防ぐための対策 • バージョン・ハッシュによる固定 ◦ ロックファイルやダイジェスト指定で依存パッケージを固定し、改ざんや意図しない更新 を防止 • リリース直後の即時採用を避ける ◦ 新しいバージョンのリリース後、一定期間を置いてから採用 • パッケージプロキシによる検証 ◦ プロキシを経由してダウンロードし、取得するパッケージを管理・検証 • ソースコード解析 ◦ 依存パッケージに悪意あるコードが含まれていないか、静的解析やサンドボックスで検 証
31. 依存関係の削減と安全なイメージの利用 Distroless イメージの採用 • シェル、パッケージマネージャー、不要な OS コンポーネントを排除 • 攻撃者が権限昇格やシステム操作に使うツールが存在しない • アプリケーションの依存関係は別途管理が必要 信頼できるベンダーへのアウトソース • Docker Hardened Images（DHI）: 脆弱性を最大 95%削減。1,000以上のイメージを提供し、 Critical/High CVE を 24時間以内 に修正。SBOM・SLSA準拠・署名付き • Chainguard Images 等、他のベンダーも同様のアプローチを提供
32. SBOM による依存関係の管理 Software Bill of Materials（SBOM） — ソフトウェア部品表 • アプリケーションの依存関係やコンテナイメージに含まれるコンポーネントを可視化 • 有事の際に脆弱なコンポーネントを迅速かつ網羅的に特定 • 依存関係のホワイトリスト / ブラックリストによる管理 課題 • 推移的依存関係の把握が難しく、階層が深くなるほど検出精度にばらつきが出る • バイナリに埋め込まれたライブラリや、リポジトリに直接コピーされた依存関係はツールの検出 対象外になることがある • 組織内の全ソフトウェアの SBOMを網羅的に取得、最新の状態に維持することが難しい • 開発端末の保護は難しい
33. コンテナイメージの改ざん対策 SLSA Provenance • ビルドの入力（ソース）、出力（成果物）、プロセスを記録した署名付き証明書で、成果物が改ざ んされていないことを保証 Sigstore / Cosign • コンテナイメージの署名・検証により、ビルドした主体と成果物の完全性を保証する Reproducible Containers • 同じソースから同じバイナリを再現可能にすることで、改ざんの検知を強化
34. 商用製品の利用について OSS やフリーソフトウェアから、商用製品への移行が現実的な選択肢に OSS で運用する場合の課題 • SLA や緊急パッチの提供がなく、脆弱性対応はすべて自組織の責任 • ツールの組み合わせやバージョン管理を自力で維持する必要がある • サプライチェーン攻撃が発生した際に、迅速かつ適切な対応ができるか不透明 商用製品を利用するメリット • 脆弱性修正の SLA が提供され、対応スピードが保証される • 商用サポートにより、インシデント対応や運用の負荷を軽減 • OSS では実現が難しい高度な機能（脅威検知、リアルタイム分析等）を利用可能
35. 最小権限と環境分離 ソフトウェアサプライチェーン攻撃による被害を最小限にするための対策 最小権限の徹底 • 開発者・CI/CD・本番環境それぞれで必要最小限の権限のみを付与 • クラウドの IAM、Kubernetes RBAC などの定期的な見直し • CI/CD のシークレットやトークンはスコープを限定し、短命なものを使用 環境分離 • 開発環境のコンテナ化により、ホストへの影響を局所化 • 開発・ステージング・本番環境を分離し、認証情報やネットワークを共有しない • CI/CD ランナーを一時的な環境で実行し、ジョブ間で状態を共有しない
36. CI/CD パイプラインの保護 基本的な対策 • サードパーティ Actions をコミットハッシュで固定 • permissions: で GITHUB_TOKEN の権限を最小限に設定 • OIDC による短命認証情報の使用（長期間有効なシークレットの排除） • pull_request_target の安全な使用 ランナーのセキュリティ強化 • セルフホステッドランナーはエフェメラル（ジョブごとに作成・破棄）で運用する • Harden-Runner 等のエージェントでランナー上のネットワーク通信、ファイル変更、プロセスを リアルタイム監視 • Egress Firewall によるアウトバウンド通信の制御（ GitHub 2026 ロードマップ） https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/ https://github.com/step-security/harden-runner
37. Kubernetes におけるサプライチェーン対策 ポリシーエンジンによるデプロイ制御 • 信頼できるレジストリの制限、特権コンテナの禁止等（ Kyverno, OPA Gatekeeper 等） • ValidatingAdmissionPolicy により外部ツールなしでも基本的なポリシー適用が可能 Kubernetes 自体のセキュリティ強化 • User Namespaces によりコンテナエスケープの影響を軽減 • RBAC 最小権限化、NetworkPolicy の徹底、seccomp / AppArmor による権限の制限等 ランタイムセキュリティ • 悪性コードの実行やコンテナエスケープをランタイムで検知 • Falco, Tetragon 等によるシステムコール・ネットワーク通信のリアルタイム監視
38. SSC のセキュリティフレームワーク Supply-chain Levels for Software Artifacts (SLSA) https://slsa.dev/ Secure Supply Chain Consumption Framework (S2C2F) https://github.com/ossf/s2c2f Microsoft - Containers Secure Supply Chain Framework (CSSC) https://learn.microsoft.com/en-us/azure/security/container-secure-supply-chain/ CNCF - Software Supply Chain Best Practices v2 https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-c hain-security-paper-v2/SSCBPv2.md CIS - Software Supply Chain Security Guide https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide
39. まとめ • ソフトウェアサプライチェーン攻撃は常態化し、悪性コードの混入や攻撃速度の加速が進んで いる • 内部ネットワークへの直接侵入が現実的になり、内部のセキュリティ対策の見直しが必要 • OSS の利用にはプロジェクトのセキュリティ体制の評価が不可欠 • 依存関係の削減、パッケージの検証、安全なイメージの利用など予防型の対策の重要性が高 まっている • 開発端末から本番環境まで、開発ライフサイクル全体でのセキュリティ対策を実施する
40. CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik Thanks! Do you have any questions? https://twitter.com/kyohmizu