コンテナセキュリティの最新事情 ~ 2026年版 ~ @kyohmizu 2026/2/12 SCSK Sysdig Bootcamp 

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 

会社紹介（10秒） https://speakerdeck.com/3shake/3shake-sreake-deck 

Kubernetes の CTF 問題を作りました 興味のある方はぜひチャレンジしてみてください！ https://github.com/kyohmizu/kubernetes-ctf-samples 

本セッションについて コンテナシステムの最新セキュリティ動向を軸に、想定される脅威や脆弱性、そして取るべ き対策についてご紹介します。 

目次 ● コンテナシステムの脅威動向 ● コンテナサプライチェーンセキュリティ ● Kubernetes セキュリティの進化 

コンテナシステムの脅威動向 01 

脅威グループ: TeamPCP Docker/Kubernetes などを標的とする攻撃キャンペーン（ 2025年12月〜） ● 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ペイロード自動展開 

脅威グループ: TeamPCP 標的 ● 公開 Docker API ● K8s API ● Ray Dashboard ● Redis ● React2Shell に脆弱なアプリケーション 目的の多様化 ● クリプトマイニング（XMRig） ● ランサムウェア展開 ● 分散プロキシ / スキャン基盤構築 ● データ窃取（Telegramで販売） https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware 

Kubernetes クラスタの攻撃インフラ化 侵害された Kubernetes クラスタがスキャン攻撃に悪用される 上位10件の攻撃元IPの特徴 ● Kubelet API (10250), kube-proxy (10256), Envoy (9964) を公開 ● Debian 12 + OpenSSH 9.2p1 で統一 → Kubernetes クラスタ自体が乗っ取られ、攻撃インフラ化 https://www.labs.greynoise.io/grimoire/2026-02-03-vive-la-vulnerabilite-french-kubernetes-cluster-hunts-your-webhook-endpoints/ 項目 数値 観測期間 2026年1月27日 〜 2月3日 総リクエスト数 33,270件（Webhookエンドポイント標的） 関与IP数 375以上 送信元 185.177.72.0/24 （97.4%）、フランスのホスティング事業者 ピーク 2月3日の2時間に全体の70%が集中 

脆弱性の悪用（React2Shell） React Server Components の深刻な脆弱性（CVE-2025-55182） ● 認証なしのRCEの脆弱性で、CVSSスコアは 10.0 ● Kubernetes においても、クラスタ上の Next.js アプリケーションが標的となる ● 公開当時、クラウド環境の 39% が脆弱なインスタンスを保有 ● 公開数時間後に中国系 APTが悪用開始 https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 

npm パッケージの侵害 メンテナーアカウントを侵害し、約 800の npm パッケージにトロイの木馬バージョンを公開 ● 約25,000の悪意ある GitHub リポジトリを作成 ● Preinstallフェーズで自動実行 - CI/CDでは同期実行、開発端末ではバックグラウンド 侵害されたパッケージ例 https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack パッケージ 組織 備考 @zapier/tunnel-agent Zapier npm普及率 27% posthog-node / posthog-js PostHog 25% / 15% ENS Domains エコシステム ENS Ethereum Name Service 関連 Postman パッケージ Postman API開発ツール 

runc: コンテナエスケープの脆弱性 Docker / Kubernetes / OCI 全般に影響するコンテナからホストへの脱出 ポイント ● 全主要クラウドプロバイダが、公開時点で修正パッチを適用 ● 内部の攻撃者または、悪意あるコンテナイメージ経由で悪用される可能性 https://www.sysdig.com/blog/runc-container-escape-vulnerabilities CVE ID CVSS 攻撃メカニズム CVE-2025-31133 7.3 maskedPaths のレースコンディション → /proc への書き込みリダイレクト CVE-2025-52565 7.3 /dev/console マウント時の競合 → ホストパスをコンテナ内にバインド CVE-2025-52881 7.3 LSMラベル適用不備 → AppArmor / SELinux バイパス 

Kubernetes: 参照権限でのコマンド実行 nodes/proxy GET権限を利用し、Kubelet API 経由で Pod 内でのコマンド実行が可能 ● 監視ツール（Datadog、Cilium等）が広くこの権限を付与 ● kubelet APIリクエストは kube-apiserver Admission Control を通らない ● 監査ログに記録されない → 検知が極めて困難 https://grahamhelton.com/blog/nodes-proxy-rce ステップ 内容 権限確認 侵害した Pod 内で、ServiceAccount が nodes/proxy の GET 権限を持っていることを確認 情報収集 nodes/proxy 経由で Node上の全Pod一覧とホストIP を取得（偵察） 接続確立 ターゲット Pod に対し、HTTP GET メソッドで WebSocket 接続を開始（ハンドシェイク） 権限回避 APIサーバー/Kubeletが「GETリクエスト」として処理するため、 CREATE 権限チェックを回避 任意実行 確立した WebSocket 経由で exec を実行し、RCE（コマンド実行）を達成 

コミュニティの議論と論点 Security Team の公式見解 RBAC は仕様通りに動作している。 HTTP GETを kubelet API 全体に許可すれば、 WebSocket GET 経由の非読み取り操作も許可される。これはバグではない。 ● CWE-1220（アクセス制御の不十分な粒度）に分類 ● 「RCE」という表現には反対。設計上コード実行を許可する権限である セキュリティ研究者の反論 ● GET権限がコード実行を許可するのは管理者の合理的な予測を超える ● 実際のペンテストで「 read-only」認識のロールから権限昇格に成功した事例 ● ノード侵害 → クラスタ全体侵害が大半の本番環境で成立 ● ブログ公開後、多数の大企業から脆弱な環境の報告が著者に寄せられた https://grahamhelton.com/blog/nodes-proxy-rce 

コンテナサプライチェーンセキュリティ 02 

ソフトウェアサプライチェーン（SCC）とは ソフトウェアの開発と提供に関わるすべてのコード、人、システム、プロセス ● 作成するコードとその依存関係 ● ソフトウェアの開発、ビルド、パッケージ化、インストール、実行に使用する内部および外部ソフ トウェア ● システムアクセス、テスト、レビュー、監視とフィードバック、コミュニケーション、承認に関するプ ロセスとポリシー ● ソフトウェアとその依存関係の開発、ビルド、保管、実行を担うシステム https://cloud.google.com/software-supply-chain-security/docs/overview 

サプライチェーン攻撃の特徴 攻撃側 ● 1つの組織、ソフトウェアの侵害から多数の組織に影響を与えることができる ● セキュリティレベルの高い組織に対し、比較的容易に侵入できる 防御側 ● アタックサーフェスが多岐にわたり、網羅的に対策を実施するのが難しい ● 組織や事業規模が大きくなるほどリスクが高まる ● サプライチェーン上の被害者にも加害者にもなり得る 

脆弱性がなければ安全か 脆弱性としては検出されない脅威がある ● 攻撃目的で作成されたツール ● 正規のOSSに混入する不正なコード ● IaCにはCVEが採番されないため、脆弱性スキャンの対象とならない → 脆弱性対策とは別に、OSSの安全性を確認する必要がある 

コンテナシステムの SCC アーティファクト アーティファクト：データの集合、成果物 ● アプリケーションのソースコード ● アプリケーションの依存関係（言語のフレームワークやライブラリ） ● アプリケーションバイナリ ● Dockerfile ● コンテナイメージ ● コンテナの依存関係（ベースイメージ、追加するパッケージ） ● インフラのソースコード（ IaC: Kubernetes Manifests, Helm Charts） https://cloud.google.com/software-supply-chain-security/docs/overview 

コンテナシステムの SCC（図） 

自社開発と OSS 利用 自社開発における責任範囲 ● ソースコードの安全性 ○ 脆弱性（バグや設定ミス）を含まないこと ● ビルドしたアプリケーション、コンテナイメージの安全性 ○ 正規の手順でビルドされたものであること ● 開発プロセスおよびシステムの安全性 OSS 利用における責任範囲 ● 利用する OSS の安全性 ○ 正規のソフトウェアであり、セキュリティ体制が整っていること ○ 脆弱性などの問題が発覚した場合に適切に対処すること 

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 CIS - Software Supply Chain Security Guide https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide 

Supply-chain Levels for Software Artifacts (SLSA) https://slsa.dev/spec/v1.2/threats-overview ソフトウェアの開発者、利用者に向けた SSC のセキュリティガイドライン ● サプライチェーンを Source, Build, Dependencies, Distribution の4つに分類 ● v1.xではビルドプロセスやプラットフォームに焦点を当てている ● ビルドにおいて、0〜3のセキュリティレベルを定義 ○ ビルド来歴（Provenance）の生成と管理 ○ ビルドプラットフォームのセキュリティ強化 ● SSC の脅威について複数の事例を紹介 ● Attestation モデル、Provenance フォーマットを定義 

Secure Supply Chain Consumption Framework (S2C2F) OSS の利用者に向けたセキュリティリスク低減のためのフレームワーク ● 8つのセキュリティプラクティスと 4つの成熟度レベルを定義 ○ ただし、レベル4はコストが高く現実的ではないと自ら述べている ● SSC の脅威について複数の事例を紹介 ● 各要件を満たすためのツール（有償 /無償）を紹介 ● 各要件を他のフレームワークと対応付け https://github.com/ossf/s2c2f 

Containers Secure Supply Chain Framework (CSSC) コンテナライフサイクル全体のセキュリティ管理、統合を目的としたフレームワーク ● コンテナのサプライチェーンを 5つのステージに分類し、プラクティスやツールを紹介 ● 通常のソフトウェアサプライチェーンと観点に相違はなく、コンテナに焦点を当てた内容 ● 実行環境のセキュリティにも言及 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-chain-security-paper-v2/SSCBPv2.md 

CIS Software Supply Chain Security Guide DevOps パイプライン向けセキュリティチェックリスト ● 合意ベースの客観的ガイドライン ● CI/CD パイプライン全体をカバー ● 他のフレームワークとは異なり、実装手順にフォーカスした実用的ガイド https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide 

Open Source Project Security (OSPS) Baseline OSS プロジェクト向けセキュリティベースライン ● 8つのコントロール、3段階の成熟度レベルで構成 ● コントロールは MUST エントリのみ ● 実用的で実行可能な推奨事項を提供 ● 外部のフレームワーク、ガイドラインとのマッピング https://baseline.openssf.org/ 

フレームワーク比較表 フレームワーク 対象 主な焦点 成熟度モデル 最終更新 SLSA 開発者/ビルドシステ ム Provenance L1-L3 (Build Track) v1.1 (2025/4) v1.2 RC2 S2C2F OSS 利用者 OSS 依存関係の管理 L1-L4 2024/8 CSSC コンテナ運用者 コンテナライフサイクル全体 ステージ別 2023/9 CNCF SSC BP v2 全ロール 包括的ベストプラクティス ペルソナ別 2024/11 CIS SSC Guide DevOps パイプラインチェックリスト チェックリスト 2022/6 OSPS Baseline OSS メンテナ プロジェクト全体のベースライ ン L1-L3 2025/10 

コンテナサプライチェーンのセキュリティ対策 SBOM による依存関係の管理 ● 有事の際の迅速かつ網羅的な検索機能 ● 依存関係のホワイトリスト /ブラックリスト 生成AIを使ったコードスキャン ● 開発環境、ビルドシステムへの悪意のあるコード混入を防止 ● スキャン精度、利便性の向上 

コンテナサプライチェーンのセキュリティ対策 Provenance による成果物の安全性担保 ● ビルドした成果物が改ざんされていないことを保証 ● Reproducible Containers の利用も検討 安全なコンテナイメージ利用 ● Docker Hardened Images（DHI）, Chainguard Images などの利用 ● 脆弱性が少なく、安全性の担保をアウトソースできる 

Kubernetes セキュリティの進化 03 

ValidatingAdmissionPolicy (v1.30 GA) Webhook 不要のCELベースポリシー検証 ● Webhook より高速（インプロセス実行） ● 外部依存がないため信頼性が高い ● OPA/Gatekeeper の代替候補として注目 https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/ apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: deny-privileged spec: matchConstraints: resourceRules: - apiGroups: [""] resources: ["pods"] operations: ["CREATE"] validations: - expression: >- !object.spec.containers.exists(c, c.securityContext.privileged == true) message: "特権コンテナは禁止されています " 

User Namespaces (v1.30 Beta) コンテナ内の root ユーザーをホストの非 root にマッピング ● コンテナ内で root (UID 0) → ホスト上では UID 65534（非特権） ● コンテナエスケープの影響を大幅に軽減 ● v1.33 でデフォルト有効化 → Feature Gate不要に https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/ apiVersion: v1 kind: Pod metadata: name: my-app spec: hostUsers: false # User Namespaces を有効化 containers: - name: app image: my-app:latest 

Kubelet Checkpoint API (v1.30 Beta) 実行中のコンテナの状態を保全する機能 ● CRIU（Checkpoint/Restore In Userspace）のコンテナ実装 ● Kubernetes v1.30 で Beta に昇格 ● 侵害されたコンテナのフォレンジックへの活用を期待 https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/ キャプチャされるデータ 内容 プロセス状態 プロセスツリー・PID・実行コンテキスト メモリ 全メモリページの完全なスナップショット ファイル オープン中のファイルディスクリプタ ネットワーク 確立済みTCPコネクション・ソケット セキュリティ seccomp / SELinux / AppArmor コンテキスト 

匿名アクセスの制限 (v1.32 Beta) kube-apiserver への匿名アクセスを許可するエンドポイントを制限 ● AuthenticationConfiguration を使用し、一部のエンドポイントのみアクセス許可 ● 匿名アクセス自体の禁止は元々可能だったが、ヘルスチェックの問題で難しかった ● system:unauthenticated に対する設定ミスや、攻撃者による永続化への対策 https://v1-32.docs.kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-authenticator-configuration apiVersion: apiserver.config.k8s.io/v1beta1 kind: AuthenticationConfiguration anonymous: enabled: true conditions: - path: /livez - path: /readyz - path: /healthz 

さいごに 

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