Containers in Cybersecurity in 2026: 脅威モデル、実践的防御、検知工学、そして運用可能な隔離設計

1. Introduction

コンテナは、2026年の企業システムにおいて事実上の標準実行単位である。マイクロサービス、AI推論基盤、データ処理パイプライン、CI/CDジョブ、さらにはエッジ環境まで、コンテナは「速く起動し、移植性が高く、運用しやすい」という利点によって広範に採用されている。しかし、その利便性は安全性を自動的に保証しない。むしろ、コンテナはホストOSカーネルを共有するため、隔離の不完全さ、権限モデルの誤設定、イメージ汚染、サプライチェーン改ざん、そしてオーケストレーション層の誤用が、従来のVM中心環境よりも短い攻撃経路を形成しうる。

2026年の実務において、コンテナ侵害は単一の“脱出”イベントだけでは説明できない。多くの実際の侵害は、まずCI/CDやレジストリ、IaCのどこかで足場を作り、その後に不十分なRBAC、特権コンテナ、過剰なCAP_SYS_ADMIN、読み書き可能なホストパス、誤設定されたServiceAccountトークン、そして過大権限のクラウドIAMロールを組み合わせて、ホストやクラスタ全体へ拡大する。したがって、コンテナセキュリティは「ランタイムだけ」でも「スキャンだけ」でも成立しない。設計、ビルド、配布、起動、監視、復旧の全段階で整合した防御が必要である。

さらに2026年は、コンテナ脅威がAI関連ワークロードと結びついた年でもある。LLM推論コンテナ、RAGパイプライン、ベクターデータベース、GPU共有ノード、モデル配布アーティファクト、そしてエージェント実行基盤は、通常のWebアプリ以上に高価値で、かつ高速展開されるため、攻撃者にとって魅力的な標的である。加えて、AIを用いたソーシャルエンジニアリングや、生成コードによる脆弱なコンテナ定義の量産は、攻撃面を一段と拡大した。したがって、本稿は2026年の現実に即して、コンテナを単なる「軽量VM」としてではなく、サプライチェーンと制御面を含む複合システムとして扱う。

本研究の目的は三つある。第一に、コンテナ環境の主要な攻撃経路を、Linuxカーネル基盤、OCIランタイム、Kubernetes制御面、クラウド統合、CI/CDの各層に分解して定式化する。第二に、2026年時点で実運用可能な防御メカニズムを、最小権限、署名検証、SBOM、eBPF、LSM、Admission Control、Policy-as-Codeの観点から統合する。第三に、評価可能な指標を定義し、現場で採用しやすい実装パターンを提示することである。これは単に理論的な提案ではなく、実際のセキュリティ運用で「どこから始めるべきか」を明確にすることを狙っている。

本稿の構成は次の通りである。まず背景として、コンテナ技術の基礎と関連研究を整理する。次に脅威モデルを形式化し、攻撃者能力と保護対象を明示する。その上で、署名・SBOM・スキャン・制御・観測を統合した方法論を提案し、実装例と評価を示す。最後に、実際の侵害シナリオをケーススタディとして分析し、2026年時点での課題と今後の方向性を論じる。

2. Background and Related Work

コンテナのセキュリティ理解には、まずOCI標準、Linuxカーネル機能、そしてオーケストレーション層の三者を分離して考える必要がある。OCI Runtime Specはコンテナ実行の標準インターフェースを定義し、runcやcrunはこの仕様に従ってプロセスを起動する。隔離の根幹はLinux namespacesとcgroupsであり、プロセスID、ネットワーク、マウント、UTS、IPC、user namespaceを分離し、資源制御を実現する。しかし、これらは完全な仮想化ではなく、カーネル共有という前提がある以上、カーネル脆弱性や権限設定の誤りが直ちに境界突破へつながる。

表1は、コンテナ、VM、マイクロVMの比較を、2026年の実運用観点で整理したものである。コンテナは起動性能と密度で優れるが、カーネル共有によるリスクが残る。VMは分離が強いが、重く、ワークロード密度が下がる。マイクロVMは中間的だが、運用複雑性が増す。

技術	分離境界	起動遅延	密度	攻撃面	代表用途
コンテナ	ホストカーネル共有	低い	高い	高い	マイクロサービス、CI、AI推論
VM	ハイパーバイザ	中程度	中程度	中程度	汎用サーバ、境界強化
マイクロVM	軽量ハイパーバイザ	低〜中	中程度	低〜中	FaaS、隔離強化、マルチテナント

関連研究では、コンテナ脱出、権限昇格、イメージ汚染、サプライチェーン攻撃、Kubernetesの設定不備が繰り返し報告されてきた。NISTはコンテナセキュリティのベストプラクティスを整理し、CISはDockerとKubernetes向けのベンチマークを提供している（NIST, 2017; CIS, 2024）。また、SLSAやin-totoはビルドの真正性、再現性、トレーサビリティを確保するための重要な枠組みとして普及した（GOOGLE, 2024）。2024年以降は、SBOMの実装がさらに一般化し、SyftやTrivy、Grypeのようなツールがコンテナ・イメージ・アーカイブの構成解析に広く使われている（ANCHORE, 2024; AQUA SECURITY, 2024）。

一方、検知技術では、FalcoやTetragon、TraceeなどのeBPFベースのランタイム可観測性が発展し、ファイルアクセス、プロセス生成、ネットワーク接続、権限変更、システムコール異常を高精度で観測できるようになった（FALCO, 2024; ISITIO, 2024）。KubernetesではOPA/GatekeeperやKyvernoによるAdmission Controlが普及し、署名検証やポリシー適用をAPIレベルで強制できるようになった（OPA, 2024; KYVERNO, 2024）。

表2は、主要防御メカニズムの比較である。単体の機能は強く見えても、攻撃者は通常、複数の弱点を連鎖させるため、層の統合が重要になる。

防御メカニズム	主な対象	強み	限界	2026年の実務的位置づけ
イメージ署名（cosign）	配布・起動前	改ざん検出	ビルド元信頼が前提	必須化が進行
SBOM（Syft/Trivy）	サプライチェーン	依存関係可視化	ゼロデイは防げない	監査・調達で重要
Admission Control	クラスタAPI	誤設定防止	バイパス経路に注意	標準制御
eBPF検知	ランタイム	高精度観測	チューニング必要	SOC連携で有効
seccomp/LSM	カーネル境界	攻撃面削減	運用難度	高リスク用途で必須

攻撃研究では、CAP_SYS_ADMIN、privileged=true、hostPath、--net=host、--pid=host、Docker socketマウント、ワイルドカードRBAC、長寿命ServiceAccount tokenなどの危険な設定が、現場侵害における典型的な踏み台であることが繰り返し示されている。特にDocker socketの露出は、コンテナからホスト上の新規コンテナ作成を通じて、実質的なホスト制御へ到達しうるため、2026年においても最も危険な誤設定の一つである。

3. Threat Model and Problem Formalization

本稿の脅威モデルでは、攻撃者は次のいずれか、または複数の能力を持つ。第一に、外部からアプリケーション脆弱性を利用して単一コンテナ内でコード実行を得る能力。第二に、CI/CDやレジストリ、依存パッケージ、Git操作などのサプライチェーンの一部に侵入する能力。第三に、Kubernetes API、クラウドIAM、メタデータサービス、Secrets管理のどれかに弱い箇所を見つけて権限拡大する能力である。攻撃者の最終目的は、機密データ窃取、横展開、永続化、暗号資産マイニング、破壊、あるいはモデル・データ汚染である。

保護対象は、$(1)$ コンテナ内部のアプリケーションとデータ、$(2)$ ノード上のホストOSとカーネル、$(3)$ Kubernetes制御面、$(4)$ イメージレジストリとビルド基盤、$(5)$ クラウド認証情報と外部API、である。これらは互いに独立ではなく、たとえばPod内のServiceAccountトークンがクラスタAPIアクセスを許し、その結果クラウドロールの操作に到達することがある。従って、境界は連鎖構造として扱うべきである。

攻撃成功確率を単純化して表すと、各層の防御突破確率を $p_i$ としたとき、全体の侵害成功確率は $$P_{\text{compromise}} = 1 - \prod_{i=1}^{n}(1-p_i)$$ で近似できる。これは各層が独立でないという現実を単純化した式にすぎないが、少なくとも単一メカニズムに依存する設計が脆弱であることを示す。運用上は、各層の誤設定率と検知遅延が重要であり、総合リスクは $$R = \sum_{i=1}^{n} w_i \cdot L_i \cdot E_i$$ と置ける。ここで $L_i$ は層 $i$ の影響度、$E_i$ は曝露度、$w_i$ は業務重要度である。

表3は、本稿で扱う代表的攻撃カテゴリを整理したものである。

攻撃カテゴリ	初期足場	主要技術	典型的な結果
コンテナ内RCE	Web/API脆弱性	シェル取得、横探索	Secrets窃取
特権誤設定悪用	privileged、hostPath	ホストファイル操作	ホスト侵害
OCI/ランタイム悪用	runc、crun、containerd	脱出、プロセス注入	ノード制御
K8s制御面悪用	RBAC、Admission、API	Pod作成、権限昇格	クラスタ拡大
サプライチェーン汚染	CI/CD、依存関係	悪性イメージ混入	永続侵害

4. Proposed Methodology

提案する方法論は、Build-Trust-Observe-Enforce の4段階から構成される。第一段階 Build では、コンテナイメージ、依存関係、生成物、署名、SBOMを一貫して生成し、再現可能性を担保する。第二段階 Trust では、レジストリからクラスタに至るまでの全アーティファクトに対し、署名検証とポリシー検証を義務化する。第三段階 Observe では、eBPF/LSM/監査ログを用いてランタイム挙動を観測し、環境ごとに基線を学習する。第四段階 Enforce では、Kubernetes Admission、seccomp、AppArmor/SELinux、NetworkPolicy、RuntimeClass、Pod Security Admissionを統合し、逸脱を拒否する。

この方法論の要点は、静的対策と動的対策を分離せず、攻撃者が通過しなければならない複数の「ゲート」を定義する点にある。例えば、イメージ署名が正しくても、ランタイムでcurl | bashが走れば侵害は成立する。逆に、ランタイムでの異常を検知できても、初期投入されたマルウェアが短時間で目的を達成するなら被害は発生する。したがって、ビルド時の真正性、配布時の完全性、起動時の許可、実行時の検知を連動させる必要がある。

提案アーキテクチャでは、サプライチェーンの信頼根をGitリポジトリの保護、CIランナーの隔離、秘密情報の短寿命化、署名鍵のKMS/HSM管理に置く。コンテナ自体は rootless を優先し、--privileged を原則禁止する。Kubernetesでは、Pod Security Admission を restricted 相当に設定し、hostNetwork、hostPID、hostIPC、hostPath、allowPrivilegeEscalation、特権capabilitiesを抑制する。必要例外は、Namespace単位の承認ワークフローと時間制限付き例外で管理する。

検知面では、Falcoルールをベースラインとして、実運用ではノイズ削減のために環境別の許可リストを構築する。例えば、/usr/bin/nc、/bin/sh、/bin/bash の常用有無、レジストリアクセス先、DNSパターン、Kubernetes APIへの到達先をプロファイル化する。eBPFによる観測は高粒度だが、過度なルール追加は可観測性の価値を下げるため、検知は「致命的操作」と「異常な経路」に集中すべきである。

実装上のポリシー例

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-privileged-containers
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]
  validations:
  - expression: "object.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || c.securityContext.privileged == false)"
    message: "privileged container is denied"

署名・検証例

syft packages docker.io/library/nginx:1.27 -o spdx-json > nginx.spdx.json
cosign generate-key-pair
cosign sign --key cosign.key docker.io/library/nginx:1.27
cosign verify --key cosign.pub docker.io/library/nginx:1.27
trivy image --severity HIGH,CRITICAL --ignore-unfixed docker.io/library/nginx:1.27

5. Implementation

実装は、Docker/Podman、containerd、Kubernetes、OPA/Gatekeeper、Falco、Cilium、Trivy、Syft、cosignを中心に構成する。開発環境では rootless Podman を優先し、ビルド環境では BuildKit を使って再現可能なイメージ生成を行う。Dockerfile では latest タグを避け、固定タグまたはダイジェスト指定を強制する。CIでは、SBOMの生成、署名、スキャン、ポリシーチェックをパイプラインに埋め込み、通過しない限りレジストリへの push を許可しない。

Kubernetes側では、Namespaceごとに LimitRange と ResourceQuota を設定し、ServiceAccount トークンの自動マウントを無効化する。必要なワークロードだけに明示的にトークンを与え、ワークロードアイデンティティは短寿命のOIDCトークンに置換する。ネットワークは Cilium で default deny を基本とし、Pod-to-Pod通信はサービス単位で許可する。重要なのは、Kubernetes NetworkPolicy だけでは可視性が不足する場面があるため、eBPF由来のフロー観測と合わせて、許可・拒否・異常の三層で判断することである。

Falco では、シェル起動、権限変更、/etc/shadow 参照、/var/run/docker.sock アクセス、nsenter、mount、setns などの高リスク操作を検知する。実運用では、単純なシグネチャ検知に加えて、コンテナごとのベースライン行動を学習し、通常のデプロイ直後に発生する初期化処理を抑制する必要がある。特に、短いジョブ型コンテナと常駐型コンテナを同じルールで扱うと誤検知が増えるため、RuntimeClassやラベルで分類するのが有効である。

kubectl create ns secure-app
kubectl label ns secure-app pod-security.kubernetes.io/enforce=restricted
kubectl -n secure-app apply -f deployment.yaml
kubectl get events -n secure-app --sort-by=.lastTimestamp
falco -r /etc/falco/falco_rules.yaml

また、開発者体験を損ねないために、ワークフローは可能な限り自動化する。たとえば、GitHub ActionsやGitLab CIで syft -> trivy -> cosign -> kubectl apply の順にし、Admission Controller でも同じポリシーを再検証する。二重化は冗長に見えるが、開発時の抜け漏れを防ぎ、本番クラスタに最終責任を持たせるために重要である。セキュリティは「前段で落とす」だけでなく、「後段で止める」設計が必要である。

6. Experimental Evaluation

評価は、実験用Kubernetesクラスタ上で、正常ワークロード、設定不備ワークロード、既知の危険操作、疑似攻撃の四種類を実行し、検知率、誤検知率、平均検知遅延、運用コストを測定した。クラスタは3ノード構成で、1台の制御面ノードと2台のワーカーノードを持つ。評価対象は、Trivyによるイメージスキャン、cosignによる署名検証、OPA/GatekeeperによるAdmission、Falcoによるランタイム検知、Ciliumによるネットワーク観測である。

評価結果の要点は、静的スキャン単独では実行時逸脱を防げず、ランタイム検知単独ではサプライチェーン汚染を防げないことである。最も安定した結果は、Admissionで危険設定を拒否しつつ、ランタイムで侵害後の挙動を検出する組み合わせだった。特に、privileged、hostPath、docker.sock マウント、CAP_SYS_ADMIN、外向き不審通信の五つを明示的に抑制すると、疑似攻撃の大半を初期段階で阻止できた。

表4は、代表的な防御手段の比較である。

防御手段	検知/防止対象	平均遅延	誤検知傾向	運用負荷
Trivyスキャン	既知CVE、設定不備	中	低	低
cosign検証	改ざん済みイメージ	低	低	低
OPA/Gatekeeper	危険なPod設定	低	低〜中	中
Falco	異常操作、脱出兆候	低	中	中
Cilium観測	不審通信、横展開	低	低〜中	中

表5は、疑似攻撃シナリオに対する検知結果の要約である。

シナリオ	Trivy	cosign	Admission	Falco	Cilium
既知脆弱イメージ配備	検出	通常	通常	通常	通常
署名なしイメージ配備	通常	失敗	通常	通常	通常
privileged Pod作成	通常	通常	阻止	通常	通常
docker.sock アクセス	通常	通常	条件次第	検出	検出
逆シェル外向き通信	通常	通常	通常	検出	検出

定量的には、複合防御は単体防御に比べて、疑似攻撃の阻止率を大きく改善した。特に Admission と Falco の組み合わせは、初期投入と侵害後行動の双方をカバーするため、被害到達率を大きく下げた。概念的には、各防御の有効性を $d_i$ とすると、複合有効性は $$D = 1 - \prod_{i=1}^{n}(1-d_i)$$ で表現でき、$n$ が増えるほど単純な直列防御より強固になる。ただし、運用ミスが増えると $d_i$ が低下するため、自動化と標準化が前提となる。

表6は、本評価で観測した運用上の指標である。

指標	単体スキャン中心	複合防御
平均検知遅延	低〜中	低
誤検知率	低	中〜低
重大誤設定の流出	高	低
インシデント封じ込め速度	中	高
開発者負荷	低	中

7. Case Study

本ケーススタディでは、実際に頻出する「コンテナ起点のクラスタ侵害」を想定する。初期侵入は、外部公開されたWebアプリのRCEである。攻撃者はアプリコンテナ内でシェルを取得し、環境変数、マウント済みSecrets、ServiceAccountトークンを探索する。もし automountServiceAccountToken: true のままで、RBACが広すぎれば、攻撃者はKubernetes APIを通じてPod一覧取得、Job作成、さらには別Namespaceでの権限拡大を試みる。

次に、攻撃者が docker.sock や hostPath、CAP_SYS_ADMIN、allowPrivilegeEscalation などの誤設定を見つけると、ホスト上での任意操作に近づく。ここでの要点は、コンテナ脱出の成功そのものより、脱出を必要としないホスト相当アクセス が現実には多いことである。たとえば、Docker socket 経由で新規特権コンテナを起動すれば、実質的にホスト支配に等しい。2026年の攻撃者は、古典的なカーネルエクスプロイトよりも、設定不備と制御面の誤用を好む傾向が強い。

本ケースでは、防御側は以下で封じ込めに成功した。第一に、Admission Controller が privileged と hostPath を拒否した。第二に、ServiceAccount トークンの自動マウントを無効化し、APIアクセスを短寿命トークンに限定した。第三に、Falco が /var/run/docker.sock へのアクセス試行と nsenter 実行を検知した。第四に、Cilium のフローモニタリングで、通常業務と異なる外向き接続先を即時可視化した。結果として、攻撃者はシェル取得後に実質的な拡大ができず、被害は単一Pod内に限定された。

この事例が示すのは、コンテナ防御が「侵入防止」だけではないという点である。侵入は前提とし、侵入後の可視化と拡大阻止で勝つべきである。現代の防御は、境界を一度守る発想から、侵入を織り込んだ継続的封じ込めへ移行している。

8. Discussion

2026年のコンテナセキュリティにおける最大の教訓は、脆弱性より設定不備の方が現実的な侵害経路になりやすいことである。もちろん、runc、containerd、Linuxカーネル、OverlayFS、eBPF、cgroupsに関連する脆弱性は依然として重大であり、CVEの追跡と迅速なパッチ適用は不可欠である。しかし、現場では「古い脆弱性がある」よりも「特権が広すぎる」「Secretが平文で置かれている」「Admissionが無効」「監視がない」ことの方が被害に直結する。したがって、運用優先度は CVE 管理だけでなく、構成管理と例外管理に置くべきである。

また、AI時代のコンテナは、従来のWebサービス以上に短命で大量展開される。その結果、手作業の審査や個別例外はスケールしない。2026年の実装で成功するのは、ポリシーをコード化し、CIで自動適用し、本番ではAdmissionとランタイムで再確認する設計である。さらに、モデル配布や推論コンテナでは、重みファイルやベクターストアの整合性、GPUドライバ依存、共有ノードの分離など、通常のWebより複雑な信頼面が存在する。AIワークロードでは、データ汚染とモデル汚染もサプライチェーンの一部として扱う必要がある。

ただし、すべてを厳しくすれば安全になるわけではない。過剰な制約は開発者の迂回を誘発し、シャドーIT化を生む。したがって、セキュリティチームの役割は「禁止」ではなく「安全な既定値の提供」である。たとえば、標準テンプレート、署名済みベースイメージ、許可済みRuntimeClass、共通NetworkPolicy、短寿命認証、既定のread-only root filesystemなどを用意し、開発者が抵抗なく安全な道を選べるようにする必要がある。

最後に、可観測性とプライバシーのバランスも重要である。eBPFや監査ログは強力だが、過剰収集は運用コストや個人情報保護上の懸念を生む。したがって、観測項目は目的限定とし、必要最小限のメタデータに絞るべきである。セキュリティは可視化の問題であると同時に、収集の統制でもある。

9. Conclusion and Future Work

本稿は、2026年時点のコンテナセキュリティを、サプライチェーン、Kubernetes制御面、ランタイム、ホスト、クラウド統合の複合問題として整理し、Build-Trust-Observe-Enforce の統合モデルを提案した。評価では、イメージスキャン、署名検証、Admission Control、eBPF検知、ネットワーク観測を組み合わせることで、単体対策では防ぎにくい侵害経路を大幅に縮小できることを示した。結論として、コンテナ防御は「軽量な隔離」ではなく、継続的な信頼検証と封じ込め設計として実装すべきである。

今後の課題は三つある。第一に、AI生成コードやAI生成コンテナ定義の増加に伴うレビュー自動化である。第二に、eBPFベース観測の精度向上と、誤検知抑制のための行動モデル化である。第三に、マルチクラウド、エッジ、GPU共有環境における分離保証の強化である。特に、ポスト量子暗号の移行や、機密計算との統合は2026年以降の重要テーマになる。コンテナは今後も中心技術であり続けるが、その安全性は「便利さ」ではなく、設計と運用の成熟度によって決まる。

References

AQUA SECURITY. Trivy documentation. 2024. Disponível em: https://trivy.dev/ . Acesso em: 8 maio 2026.

ANCHORE. Syft documentation. 2024. Disponível em: https://github.com/anchore/syft . Acesso em: 8 maio 2026.

CIS. CIS Docker Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/docker . Acesso em: 8 maio 2026.

CIS. CIS Kubernetes Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes . Acesso em: 8 maio 2026.

CNCF. Kubernetes documentation. 2026. Disponível em: https://kubernetes.io/docs/ . Acesso em: 8 maio 2026.

CNCF. containerd documentation. 2026. Disponível em: https://containerd.io/ . Acesso em: 8 maio 2026.

COSEGAN? No; corrected below.

COSEGAN?