> 「コンテナイメージの 70% 以上は少なくとも 1 件の既知の高リスク CVE を含む。2026 年のコンテナセキュリティは『スキャンするかしないか』ではなく『どの段階で、どのツールで、どう自動化するか』の問題だ。」— Sysdig 2025 Cloud-Native Security Report

コンテナセキュリティスキャンは 2017 年の Clair、2019 年の Trivy 初版リリース以降、過去 7〜8 年で爆発的に進化しました。2026 年 5 月現在、単一の「イメージスキャナ」カテゴリはもはや存在しません。**イメージ脆弱性スキャン (SCA)、ランタイムセキュリティ、K8s 設定不備、サプライチェーン、CNAPP** の 5 つの分野に業界は分かれ、各分野はさらにオープンソースと商用の二陣営に枝分かれしています。

この記事では、Trivy・Grype・Syft・Clair・Snyk Container・JFrog Xray・Sysdig Secure・Wiz・Orca・Prisma Cloud・Aqua・CrowdStrike Falcon CS などのイメージ脆弱性/CNAPP ツール、Falco・Tetragon・Tracee などの eBPF ベースランタイムセキュリティ、Kubescape・Datree・kube-bench・kube-hunter・Polaris・kube-score・Checkov などの K8s 設定不備スキャナ、Cosign・Sigstore・Rekor・Fulcio・SLSA・in-toto のサプライチェーンセキュリティ、CycloneDX・SPDX の SBOM フォーマット、そして Chainguard・Distroless・Wolfi のハードニングイメージまで一気に整理します。

1. 2026 年のコンテナセキュリティ地図 - 4 ドメイン + CNAPP

コンテナセキュリティはよく「イメージスキャン」と省略されますが、2026 年の実際の対象範囲は 4 つのドメインに分かれます。

| ドメイン | 中心的な問い | 代表ツール |

|---|---|---|

| イメージ脆弱性 (SCA) | イメージ内に既知 CVE があるか | Trivy, Grype, Clair, Snyk Container |

| 設定/IaC スキャン | Dockerfile/マニフェスト/IaC は安全か | Trivy Config, Checkov, Kubescape |

| ランタイムセキュリティ | コンテナは不審な振る舞いをしていないか | Falco, Tetragon, Tracee, Sysdig |

| サプライチェーン | イメージは信頼できる出所か | Cosign, Sigstore, in-toto, SLSA |

この 4 ドメインの上に、**CNAPP (Cloud-Native Application Protection Platform)** という統合カテゴリが乗ります。CNAPP は上記 4 つに加え CSPM (Cloud Security Posture Management) と CIEM (Cloud Infrastructure Entitlement Management) を 1 つのコンソールで提供する統合プラットフォームで、Wiz、Prisma Cloud、Orca Security、Sysdig Secure、Lacework、CrowdStrike Falcon Cloud Security が市場を二分しています。

2026 年のセキュリティチームはほぼ例外なく、「オープンソースツールでビルドパイプラインのゲートを作り、CNAPP を 1〜2 個でランタイム/クラウド全体をカバーする」というハイブリッド戦略を採用します。すべてを無料 OSS でまかなうチームも、すべてを単一の CNAPP に任せるチームも、徐々に減っています。

2. イメージ脆弱性スキャナの動作原理 - SCA (Software Composition Analysis)

イメージ脆弱性スキャンは本質的に 2 段階です。

1. **インベントリ作成** — イメージ内のどの OS パッケージ (apt/apk/rpm)、どの言語ライブラリ (npm/pip/Maven/Go modules) があるかを目録化

2. **CVE マッチング** — 抽出したインベントリを CVE データベース (NVD・OSV・GHSA・Red Hat OVAL) と突き合わせ

1 段階の成果物が事実上の **SBOM (Software Bill of Materials)** で、Syft・Trivy・Snyk Container はいずれも内部で似たことをしています。違いは CVE データベースの厚み、マッチング精度、false-positive 処理、付加機能 (設定スキャン、シークレット検出、ライセンス分析) です。

CVE データベースも一枚岩ではありません。**NVD (米 NIST)**、**OSV (Google)**、**GHSA (GitHub Security Advisories)**、**Red Hat OVAL**、**Alpine SecDB**、**CNNVD (中国)**、**JVN (日本)** がそれぞれ異なるペースで更新され、各ツールが自前のバックエンドでマージして使用します。Trivy は Aqua が運営する独自脆弱性 DB を GHCR から定期更新し、Grype は Anchore の grype-db を使います。

3. Trivy 0.58 (Aqua Security) - オープンソース標準の地位

Trivy は 2019 年、Aqua Security が買収した日本人開発者 (masahiro331) のサイドプロジェクトとして始まり、2026 年現在では事実上の **CNCF 推奨オープンソーススキャナ標準** となりました。GitHub スター 22,000+、Apache 2.0 ライセンス、2025 年末時点で 0.58.x 安定版がメインストリームです。

Trivy の強みは **単一バイナリで全てをカバーする点** です。

- OS パッケージ (Alpine, Debian, Ubuntu, RHEL, CentOS, Photon, Oracle, Wolfi, Chainguard, Bottlerocket, Amazon Linux 2/2023)

- 言語ライブラリ (npm, yarn, pnpm, pip, Poetry, Pipenv, Maven, Gradle, Go modules, Cargo, Composer, NuGet, Bundler, Conan)

- IaC 設定 (Dockerfile, Kubernetes YAML, Terraform/OpenTofu, CloudFormation, Helm Chart, Kustomize)

- シークレット (AWS access key, GCP service account, GitHub token など 100 種類超のパターン)

- ライセンス (GPL/AGPL/MIT/Apache 分類)

- SBOM 生成/取り込み (CycloneDX, SPDX)

基本的な使い方は非常にシンプルです。

イメージ脆弱性スキャン

trivy image ghcr.io/myorg/api:1.2.3

ファイルシステム (CI でビルド成果物をスキャン)

trivy fs --severity HIGH,CRITICAL .

Kubernetes クラスター全体スキャン

trivy k8s --report=summary cluster

IaC スキャン

trivy config ./deploy/

SBOM 生成 (CycloneDX)

trivy image --format cyclonedx --output sbom.cdx.json myimage:tag

CI パイプラインでは `--exit-code 1 --severity CRITICAL --ignore-unfixed` オプションが標準的な組み合わせです。CRITICAL かつ fix が存在する CVE のみビルドを失敗させ、false-positive 疲れを大幅に削減します。

4. Grype + Syft (Anchore) - SBOM-first アーキテクチャ

Anchore の Grype と Syft は Trivy の最も近い競合です。両方とも Apache 2.0 で、思想がわずかに異なります。

- **Syft**: インベントリ → SBOM 生成

- **Grype**: SBOM → CVE マッチング

この分離は **SBOM-first ワークフロー** に自然にハマります。CI で一度 Syft で SBOM を生成し、同じ SBOM を後で何度も Grype でリスキャンできます。新しい zero-day CVE が公開されたとき、イメージを再ビルドせずに既存の SBOM だけを再マッチングして影響範囲を即座に評価できる、という意味です。

Syft で SBOM 生成

syft myimage:latest -o cyclonedx-json > sbom.json

Grype で SBOM スキャン

grype sbom:./sbom.json

あるいはイメージ直接スキャンも可

grype myimage:latest

Trivy も事実上同じワークフローをサポートしますが、Anchore 陣営は最初から SBOM を 1 級オブジェクトとして扱ってきたため、SLSA・in-toto・Cosign attestation との統合がより自然です。米国政府 (NIST SP 800-218 SSDF, EO 14028) が SBOM 義務化に舵を切る中、Syft の採用が急速に伸びています。

5. Clair v4 (Quay / Red Hat) - レジストリ統合型スキャナ

Clair は 2015 年に CoreOS (現 Red Hat) が作った最古のオープンソースコンテナスキャナです。2026 年現在 v4 が安定版で、Apache 2.0 ライセンスで GitHub にホスト。

Clair の特徴は「スキャナライブラリ + HTTP サーバ」アーキテクチャです。単独 CLI で使うより、**Quay・Harbor・JFrog Artifactory などのコンテナレジストリに埋め込まれて** 動作するのが一般的。Quay は Clair を内蔵してイメージ push 直後に自動スキャンし、結果を UI に表示します。

- 長所: レジストリ統合がきれい、OpenShift/Red Hat エコシステムと結合、インデキシングとマッチングを分けて水平拡張が容易

- 短所: 単独 CLI の使い勝手は Trivy/Grype に比べると弱い、IaC/シークレット/SBOM などの付加機能はなし

- 採用先: Red Hat OpenShift Quay、IBM Cloud Container Registry の一部

Red Hat エコシステム以外では Trivy が事実上第一候補ですが、OpenShift で標準化された組織 (主に金融・通信) では Clair が依然デフォルトです。

6. Snyk Container - 商用 SCA の代表格

Snyk は 2015 年に英国で創業したセキュリティ企業で、2024 年に ARR 9 億ドルを突破した商用 SCA の代表格です。**Snyk Open Source** (ライブラリ脆弱性)、**Snyk Container** (イメージ)、**Snyk IaC** (Terraform/K8s)、**Snyk Code** (SAST) の 4 製品を 1 つのコンソールで提供します。

Snyk Container の強みは 2 つ。

1. **修正ガイド (Fix Advice)**: 単純に CVE リストを並べるのではなく「ベースイメージを X から Y に変えれば CRITICAL が 5 件消える」のような具体的な提案を出す

2. **Snyk Vulnerability Database**: NVD より平均で数日〜数週間早くキュレーションされる独自 DB

価格は 2026 年 5 月時点で Team プランが開発者あたり月額 $98 程度から、Enterprise は別途見積もり。無料プランは月 200 回までスキャンを許可しており、個人プロジェクトや小規模チームには十分実用的です。

Snyk が Trivy に対して明確に優位な点は **アラート・チケッティング・管理コンソール** です。Jira・Slack・MS Teams 連携、優先度自動付与、ライセンス分析、ポリシー管理など「運用」機能が厚い。ビルドゲートは Trivy が、運用後追は Snyk が担うという分業もよく見られます。

7. JFrog Xray・Sysdig Secure・Aqua Security - 商用コンテナセキュリティ BIG3

商用コンテナセキュリティ市場は、かつて Snyk + Aqua + Sysdig + Twistlock (現 Prisma Cloud) の 4 強構図でしたが、2026 年も大きな変化はありません。

- **JFrog Xray** — JFrog Artifactory と一体。Artifactory を使う現場では自然な選択。SCA・ライセンス・CVE・OSS Compliance を統合

- **Sysdig Secure** — Falco の商用親会社。ランタイムセキュリティに強く、イメージ/IaC スキャンも備える。eBPF ベースの deep visibility が差別化要素

- **Aqua Security** — Trivy の親会社。オープンソースの Trivy に加え、商用 CSPM/CWPP + ランタイム + サプライチェーンを統合。**Tracee** (eBPF ランタイム) も Aqua の運営

3 社とも Snyk と同程度の価格帯 (開発者/ノードあたり月 $50〜$200) で、見積もりは環境規模により変動が大きい。Wiz・Prisma Cloud・Orca などの CNAPP が台頭する中、BIG3 自体も CNAPP カテゴリへ拡張中ですが、「ランタイムセキュリティ + イメージスキャン」中心のカラーは依然強いです。

8. Falco (CNCF) - eBPF ランタイムセキュリティの標準

Falco は 2016 年に Sysdig が作成、2018 年に CNCF に寄贈、2024 年 2 月に Graduated 段階に到達しました。Apache 2.0 ライセンスで、**eBPF またはカーネルモジュールベースでシステムコール・K8s 監査・クラウドイベントをリアルタイム監視** します。

代表的なルール:

- コンテナ内で shell が実行された

- privileged コンテナの作成試行

- ホストファイルシステム (`/etc`, `/proc`) へのコンテナの書き込みアクセス

- 新規ポートでの外部通信開始

- 異常な位置 (`/tmp`, `/dev/shm`) からのバイナリ実行

ルールは YAML で定義され、MITRE ATT&CK マッピングを含む約 100 個のデフォルトルールが提供されます。

- rule: Shell in Container

desc: Notice shell activity within a container

condition: >

spawned_process and container

and shell_procs

and proc.tty != 0

and container_entrypoint

output: >

Shell spawned in a container

(user=%user.name container_id=%container.id image=%container.image.repository)

priority: WARNING

tags: [container, shell, mitre_execution]

Falco の出力は stdout、syslog、Kafka、HTTP webhook、Falco Sidekick を経由して Slack/PagerDuty/SIEM に転送されます。運用上の最大の課題はノイズチューニングで、最初の 1〜2 週間はほぼすべてのルールが false-positive 爆弾になるため、ホワイトリスト作業が必須です。

9. Tetragon (Isovalent / Cilium) - eBPF ランタイムの新世代

Tetragon は Cilium で有名な Isovalent (2024 年 Cisco 買収) が作った **eBPF ベースのランタイムセキュリティ + オブザーバビリティ** ツールです。Apache 2.0 ライセンスで、CNCF Cilium プロジェクトの一部。

Falco との違い:

- Tetragon は **検知だけでなく強制 (Enforcement) も可能** — eBPF が syscall を直接拒否できる

- Cilium ネットワークポリシーと自然に結合 — L3/L4/L7 トラフィック可視性と syscall 可視性を 1 つのデータモデルで統合

- TracingPolicy CRD という K8s ネイティブなルールモデル — Falco の YAML ルールより K8s 親和的

- パフォーマンスオーバーヘッドが低いとされる (ベンダー主張、実測はワークロード依存)

2026 年 5 月時点で Tetragon は Falco より採用率は低いものの、すでに Cilium を運用する組織にとって自然な次の一歩として急速に拡大中。Isovalent が Cisco に買収されたことで商用サポート (Isovalent Enterprise) も一段と強化されました。

10. Tracee (Aqua Security) - Trivy のランタイム相棒

Tracee は Aqua Security のもう一つの **eBPF ベースランタイムセキュリティツール** です。Apache 2.0、2026 年現在 v0.21.x 安定版がメインストリーム。

Tracee の差別化要素は **フォレンジック (Forensic) 志向** です。単なるイベント通知を超えて syscall 系列、プロセスツリー、ファイルアクセスパターンを豊富に記録し、事後の侵害分析に強い。独自シグネチャ約 100 個で、cryptominer、fileless attack、container escape、kernel exploit といった脅威を検知します。

Falco・Tetragon・Tracee の中から選ぶ際の一般的なガイドライン:

- Cilium ベースのクラスター → Tetragon が自然

- すでに Sysdig Secure 利用中 → Falco がバックエンド

- Aqua Trivy/Aqua Enterprise ラインアップ → Tracee が相棒

- それ以外の出発点は Falco — コミュニティが最大でルールセットが豊富

11. Kubescape (Armo) - NSA Hardening Guide マッピング

K8s 設定不備スキャナの代表は Kubescape です。イスラエルの Armo が 2021 年にオープンソース化し、2022 年に CNCF Sandbox 入り、2023 年 11 月に Incubating 段階へ昇格しました。Apache 2.0 ライセンス。

Kubescape の最大の差別化要素は **NSA/CISA Kubernetes Hardening Guide** と **MITRE ATT&CK for Containers** を 1 級でマッピングすること。単なる best-practice チェックではなく「この設定不備はどの NSA 勧告とどの ATT&CK 技法に該当するか」を結果レポートに併記します。

クラスター全体スキャン

kubescape scan

特定フレームワーク

kubescape scan framework nsa

kubescape scan framework mitre

kubescape scan framework cis-eks-t1.2.0

マニフェストスキャン (CI)

kubescape scan ./deploy/

2026 年 5 月時点で Kubescape は in-cluster Operator モード、Helm chart スキャン、Network Policy 自動生成、attack-path 分析などの高機能を追加し、事実上無料の CNAPP に近い形へ進化中です。Armo Platform という商用 SaaS も別途提供されます。

12. kube-bench・kube-hunter・kube-score・Polaris - CIS ベンチマーク 4 兄弟

Aqua Security の **kube-bench** は、**CIS Kubernetes Benchmark** を自動チェックする最古のツールです。各ノードで kubelet/apiserver/etcd の設定を点検し、CIS Pass/Fail レポートを出力します。クラウドマネージド K8s (EKS・GKE・AKS) 用の専用プロファイルも提供。

**kube-hunter** は同じく Aqua のペンテスト型スキャナで、クラスター外部/内部から「攻撃者視点」で露出した脆弱性を能動的に探します。ただし 2024 年から archived となっており、新規機能追加は止まっているため新規採用は推奨されません。

**kube-score** は Zegl 制作のワークロードマニフェスト静的解析ツールで、「Pod に securityContext がない、ResourceLimits が抜けている、ImagePullPolicy が Always ではない」といったベストプラクティス違反を検出します。CI に軽量ゲートとして組み込みやすい。

**Polaris** (Fairwinds, 2018) は同じく K8s ベストプラクティススキャナですが、in-cluster Dashboard モードと Admission Controller モードの両方を提供し、運用親和的です。Fairwinds Insights という商用 SaaS もあります。

この 4 つは領域が重なりますが、典型的な組み合わせは **CIS ベンチマーク = kube-bench**、**ワークロード静的解析 = kube-score + Polaris**、**総合的なセキュリティ姿勢 = Kubescape** です。

13. Datree - ポリシー as コードの短い栄光

Datree は 2020 年に登場した K8s ポリシー as コードスキャナで、一時「GitOps フレンドリーな OPA 代替」として大いに注目を集めました。ポリシーを yaml で定義してマニフェストを検証する方式が非常に直感的でした。

しかし 2023 年 12 月、Datree は GitLab に買収され、2024 年以降オープンソース活動は事実上停止しました。2026 年現在、新規採用は推奨されず、類似領域は **OPA Gatekeeper**、**Kyverno**、**Kubescape** が吸収しました。

ただし Datree のポリシー as コードモデル自体は生き残り、Kubescape Control Library や Kyverno ClusterPolicy に影響を与えました。歴史的文脈で名前を覚えておく価値はあります。

14. Checkov (Palo Alto Networks / Bridgecrew) - IaC スキャナの第一人者

Checkov は Bridgecrew が作った IaC スキャナで、2021 年に Palo Alto Networks に買収され Prisma Cloud の一部になりました。Apache 2.0 オープンソースで、**Terraform・CloudFormation・Kubernetes・Helm・Kustomize・Dockerfile・ARM・Bicep・Serverless** といった主要 IaC フォーマットを 1 ツールでカバーします。

Terraform ディレクトリスキャン

checkov -d ./terraform/

特定の K8s マニフェスト

checkov -f ./deploy/web.yaml

SARIF 出力 (GitHub Code Scanning 連携)

checkov -d . -o sarif > checkov.sarif

Trivy Config と領域が正確に重なりますが、Checkov はルールセットがはるかに豊富 (800+) です。一方、単一バイナリの軽さは Trivy が上。CI 段階で両者を並列実行する組織も多い。

15. OPA Gatekeeper・Kyverno - Admission Control 二強

スキャンとは別に、**クラスター進入を阻止する** Admission Control の 2 つの標準は **OPA Gatekeeper** と **Kyverno** です。

- **OPA Gatekeeper** — CNCF Graduated。Rego DSL でポリシー記述。表現力は最強だが学習コストが高い

- **Kyverno** — CNCF Graduated (2024 年卒業)。YAML でポリシー記述。K8s マニフェスト変形 (Mutating) もサポート。学習コストが非常に低い

スキャナ (Trivy/Kubescape/Checkov) が「コードレビュー段階」なら、Gatekeeper/Kyverno は「ランタイムゲート」。両段階を備えて初めて真の defense-in-depth になります。2026 年の新規導入では Kyverno の採用率が OPA Gatekeeper を上回っています。

16. Sigstore - Cosign / Rekor / Fulcio で見るサプライチェーン署名

**サプライチェーンセキュリティ** の事実上の標準は Linux Foundation 配下の **Sigstore** プロジェクト。3 つのコンポーネントが中核です。

- **Cosign** — イメージ/アーティファクトの署名・検証 CLI

- **Fulcio** — OIDC 身元から短命 (short-lived) X.509 証明書を発行する CA

- **Rekor** — すべての署名記録を保存する改ざん不可な透明性ログ

Cosign の魅力は **keyless signing** です。開発者が別途秘密鍵を保管せず、GitHub Actions OIDC トークンを Fulcio に提示してその場で発行される短命証明書で署名します。署名そのものは Rekor に永久に記録されます。

署名 (keyless, GitHub Actions から)

cosign sign --yes ghcr.io/myorg/api:1.2.3

検証

cosign verify ghcr.io/myorg/api:1.2.3 \

--certificate-identity-regexp='^https://github.com/myorg/' \

--certificate-oidc-issuer='https://token.actions.githubusercontent.com'

SBOM attestation 添付

cosign attest --predicate sbom.cdx.json \

--type cyclonedx \

ghcr.io/myorg/api:1.2.3

2026 年 5 月現在、GitHub Container Registry、Google Artifact Registry、AWS ECR のすべてが Sigstore 署名を認識し、Kyverno と OPA Gatekeeper は admission 段階で署名検証を強制できます。

17. SLSA・in-toto - サプライチェーン信頼レベルフレームワーク

**SLSA** (Supply-chain Levels for Software Artifacts、「サルサ」と発音) は Google が 2021 年に公開したサプライチェーン信頼レベルフレームワーク。2023 年に v1.0、2025 年に v1.1 が安定版で、現在は OpenSSF が運営します。

SLSA はビルド環境の整合性を L1〜L4 の 4 段階で定義します。

- **L1** — ビルドのスクリプト化、出所 (provenance) 記録

- **L2** — ホストされたビルドシステム、認証済み provenance

- **L3** — 隔離されたビルド、改ざん不可な provenance

- **L4** — 2 人レビュー、再現可能なビルド

**in-toto** は SLSA の標準データフォーマットで、ビルド各段階のメタデータ (誰が、いつ、何をビルドしたか) を署名付き JSON で記録します。Cosign の `cosign attest` は内部で in-toto attestation を生成し Rekor に登録します。

GitHub Actions は 2024 年から自動 SLSA L3 ビルドプロビナンス (attestation) をサポートし、2026 年 5 月時点で主要オープンソースプロジェクト (Kubernetes、Cilium、Istio など) のほとんどが L3 ビルド認証を添付してリリースしています。

18. CycloneDX・SPDX - SBOM フォーマット 2 標準

SBOM 標準は 2 つに分かれています。

- **CycloneDX** (OWASP, 2017) — XML/JSON、セキュリティ志向。VEX (Vulnerability Exploitability eXchange) と統合

- **SPDX** (Linux Foundation, 2010) — Tag-Value/JSON/YAML、ライセンス志向。ISO/IEC 5962:2021 国際標準

Trivy・Syft・Snyk Container はすべて両フォーマットを出力できます。実務での選択ガイドライン:

- セキュリティ中心 (脆弱性追跡・VEX) → CycloneDX

- ライセンス/コンプライアンス中心 → SPDX

- 米国政府納入 → どちらでも可だが SPDX のほうが安全

米 NIST SP 800-218 SSDF と EU Cyber Resilience Act (CRA、2024 年発効、2027 年強制) が SBOM 義務化を明示するなか、どちらを選ぼうと SBOM 自体は 2026 年の標準成果物になりました。

19. CNAPP ビッグ 5 - Wiz・Prisma Cloud・Orca・Sysdig・Lacework

商用 CNAPP 市場は 2026 年 5 月時点で 5 強が競合します。

- **Wiz** — イスラエルのスタートアップ、2024 年に評価額 120 億ドル。agentless スキャンが差別化要素。2025 年に Google 買収説があったが不成立

- **Prisma Cloud** (Palo Alto Networks) — Twistlock (2019) + Bridgecrew (2021) + RedLock 買収で構成された巨人。最も広いカバレッジ

- **Orca Security** — イスラエル。SideScanning 技術でエージェントなしでクラウド資産を統合分析

- **Sysdig Secure** — Falco をベースとしたランタイム強者。agent-based の deep visibility

- **Lacework** — データモデルベースの異常検知。2024 年に Fortinet 買収

加えて **CrowdStrike Falcon Cloud Security** (エンドポイントの強者がクラウドへ拡張)、**Aqua CSPM**、**Microsoft Defender for Cloud**、**Datadog Cloud Security Management** が後発として急成長中。

CNAPP の選定は通常「すでに利用しているクラウドセキュリティ/監視ベンダーが誰か」に強く依存します。Datadog を使う現場は自然に Datadog CSPM、MS Azure 中心の組織は Defender for Cloud が第一候補、という具合です。

20. CSPM vs CWPP vs CIEM - CNAPP の中の 3 つの略語

CNAPP の中には 3 つのサブカテゴリがあります。

- **CSPM** (Cloud Security Posture Management) — クラウド設定ミス (S3 public、過大な IAM 権限) の点検

- **CWPP** (Cloud Workload Protection Platform) — ホスト/コンテナ/サーバーレスランタイムワークロードの保護

- **CIEM** (Cloud Infrastructure Entitlement Management) — IAM/RBAC 権限の最小化分析

2026 年の CNAPP はこの 3 つを吸収しつつ、さらに **Code Security** (SAST)、**Container Security**、**Kubernetes Security Posture Management (KSPM)**、**Data Security Posture Management (DSPM)** まで外延を拡張中。「セキュリティツール 30 個」時代を終わらせ、1 つのコンソールで全部見るという野望です。

ただし CNAPP がすべてを吸収できるわけではありません。深い SAST は依然 Snyk Code/Semgrep/Checkmarx、OSS ライセンスは FOSSA/Black Duck、シークレットスキャンは GitGuardian が強い。CNAPP は「基本のカバー」を担い、カテゴリ別の専門ツールが深さを埋めるのが一般的な構図です。

21. イメージハードニング - Chainguard・Distroless・Wolfi・Bitnami Secure

スキャンだけでは不十分です。そもそもイメージベースを小さく安全に作る **イメージハードニング (Image Hardening)** も 2026 年の大きなトレンド。

- **Distroless** (Google, 2017) — シェル・パッケージマネージャーなしで、ランタイムのみを含む静的イメージ。`gcr.io/distroless/static`、`gcr.io/distroless/java21`。シェルがないため exec ベースの侵害がほぼ不可能

- **Wolfi** (Chainguard, 2022) — distroless 思想を持つ apk ベースのディストリビューション。一般的なパッケージマネージャーの互換性を維持しつつ、小さくクリーン

- **Chainguard Images** (2022〜) — Wolfi ベースの商用イメージカタログ。約 1,000 イメージが毎日ビルドされ、zero-CVE を目標とする。無料の Developer ティアあり

- **Bitnami Secure Images** (Broadcom, 2024) — Bitnami が Broadcom に買収された後に発売された商用セキュアイメージライン

- **Mariner Linux** (Microsoft、現 Azure Linux) — Microsoft 製のコンテナ志向ミニマル Linux。AKS のノード OS としても利用

- **Alpine Linux** — 最古のミニマルイメージ。musl libc と apk パッケージが特徴。一部 glibc 依存問題で上位環境では distroless/Wolfi へ移行する傾向

- **Red Hat UBI** (Universal Base Image) — Red Hat の無料再配布可能イメージ。エンタープライズ親和的

ベースイメージを Distroless/Wolfi に変えるだけで Trivy スキャン結果の CVE 数が数十〜数百件減ることはよくあります。一部組織はセキュリティポリシーとして「許可されたベースイメージのアロウリスト」だけを設定することも。

22. CI/CD 統合 - GitHub Actions / GitLab CI / Argo Workflows

スキャンツールはほぼすべて、整理された GitHub Actions と GitLab CI コンポーネントを提供します。代表的なパターン:

.github/workflows/security.yml

name: container-security

on:

push:

branches: [main]

pull_request:

jobs:

trivy:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Build image

run: docker build -t myapp:${{ github.sha }} .

- name: Trivy scan (image)

uses: aquasecurity/trivy-action@0.28.0

with:

image-ref: 'myapp:${{ github.sha }}'

severity: 'CRITICAL,HIGH'

exit-code: '1'

ignore-unfixed: true

format: 'sarif'

output: 'trivy.sarif'

- name: Trivy config (IaC)

uses: aquasecurity/trivy-action@0.28.0

with:

scan-type: 'config'

severity: 'CRITICAL,HIGH'

exit-code: '1'

- name: Upload SARIF

if: always()

uses: github/codeql-action/upload-sarif@v3

with:

sarif_file: 'trivy.sarif'

運用のヒント:

- `--ignore-unfixed` は新規ビルドを無差別に失敗させないためほぼ必須

- `severity: CRITICAL,HIGH` で開始、false-positive が多ければ MEDIUM はレポートのみ (non-blocking)

- 結果は SARIF で GitHub Code Scanning または GitLab Security Dashboard にアップロード

- PR コメントボットはセルフホスト可 (`reviewdog` + Trivy)

23. 韓国の事例 - AhnLab CloudSec・Snyk Korea・NAVER Cloud・Toss

韓国でもコンテナセキュリティの導入は速いです。

- **AhnLab CloudSec** — 安博 (AhnLab) の CNAPP ラインアップ。2024 年発売、CSPM・CWPP・CIEM を統合提供。国内金融/公共認証適合性に強み

- **Snyk Korea** — 2023 年に韓国法人設立、国内大手 IT 企業の多くで採用。Kakao・NAVER・Coupang の一部部門で利用

- **NAVER Cloud Container Security** — NAVER Cloud Platform のコンテナレジストリ (NCR) が内蔵スキャンを提供、Trivy ベース

- **Kakao Korea Container Hardening** — Kakao 社内で運用する自社ベースイメージ + Trivy ゲート

- **Toss** — 2024〜2025 年にコンテナセキュリティ標準化を発表 (NHN FORWARD、Toss SLASH)。Trivy + Kyverno + Falco の組み合わせと独自 admission ポリシーで知られる

- **Samsung SDS** — Brity Cloud のコンテナセキュリティラインアップ保有。独自 EAL 認証コンテナプラットフォームを提供

- **LG CNS / SK C&C** — 大手 SI も独自のコンテナセキュリティフレームワーク保有

韓国市場は KISA (韓国インターネット振興院) の ISMS-P 認証、金融保安院ガイドライン、公共 ISMS 要件のため、グローバル CNAPP だけでは不十分なことが多く、国内ベンダーと結合したハイブリッド構成が一般的です。

24. 日本の事例 - Mercari・Yahoo!Japan・LINE・CyberAgent

日本のコンテナセキュリティ導入も非常に積極的です。

- **Mercari** — 2018 年から GKE、2021 年から Trivy 導入。2024 年には Wiz 採用事例を公開発表 (Mercari Engineering Blog)

- **Yahoo!Japan** (現 LY Corporation) — Falco を大規模に運用、独自ルールセットと SaaS のような社内プラットフォームを提供

- **LINE Yahoo** — LY 合併後にセキュリティ標準統合を進行中、Trivy + Falco + 独自 IaC ゲート

- **CyberAgent** — AbemaTV/Ameba などで GKE/EKS を運用、Kubescape + Trivy の組み合わせ採用事例を公開

- **DeNA、GREE** — ゲーミング/モバイルワークロード保護で Aqua/Sysdig を採用

- **NTT Communications** — NTT 独自の CNAPP ラインアップ保有、日本政府・通信顧客中心

日本は PCI-DSS・ISMAP (政府クラウド認証) 要件のためセキュリティツール導入が速く、「オープンソース + 日本 SaaS」のハイブリッドが標準です。

25. 費用 - オープンソース $0、Snyk $98+/dev、CNAPP Wiz/Orca は要見積もり

2026 年 5 月時点のコンテナセキュリティツールの費用感。

| カテゴリ | ツール | 費用 |

|---|---|---|

| OSS イメージ/IaC スキャナ | Trivy, Grype, Syft, Clair, Checkov | $0 |

| OSS ランタイムセキュリティ | Falco, Tetragon, Tracee | $0 |

| OSS K8s 設定不備 | Kubescape, kube-bench, Polaris, kube-score | $0 |

| Snyk Container | Team プラン | 開発者あたり月 $98+ |

| Sysdig Secure | Cloud プラン | ノードあたり月 $25〜$75 (見積) |

| Aqua Enterprise | 全体 | 別途見積、100 ノード約年 5 万〜15 万ドル |

| Wiz / Orca | 全体 | 別途見積、クラウド資産規模ベース |

| Prisma Cloud | Compute Edition+ | 別途見積、モジュール別課金 |

| Chainguard Images | Developer ティア | 無料 (制限イメージ) / Custom (全体) |

多くの組織の現実的な出発点は「Trivy + Falco + Kubescape 無料」でビルド/ランタイムの基本を押さえ、規模が拡大したら CNAPP または Snyk の導入を検討する流れです。いきなり Wiz の導入に踏み込むと年に数十万ドルが即発生するため、段階的な導入が一般的です。

26. 今後の展望 - AI 自動トリアージ、eBPF 標準化、政府 SBOM 義務化

2026 年以降に明確な 3 つの流れ。

1. **AI 自動トリアージ (Auto Triage)** — Snyk、Wiz、Sysdig はいずれも LLM で CVE false-positive 自動分類、fix-PR 自動生成機能を提供。Trivy も OSS 側で GitHub Copilot Security との統合を強化中

2. **eBPF 標準化** — Falco/Tetragon/Tracee が結局似たシグナルを異なるフォーマットで出している現状から、OpenTelemetry/eBPF Foundation 主導で標準イベントスキーマ作業が進行中

3. **政府 SBOM 義務化** — 米国 EO 14028、NIST SSDF、EU CRA (2027 強制)、韓国 KISA ガイドラインまで、SBOM 添付が事実上の納入条件となる時点が 2027 年前後に到来

加えて **コンテナ外領域への拡張** も加速。サーバーレス関数スキャン、Wasm モジュールスキャン、AI モデルアーティファクトスキャン (Hugging Face モデルカード、ML SBOM) などが CNAPP の新モジュールとして吸収されつつあります。

結論 - 「どこで止めるか」 4 レイヤーディフェンス戦略

2026 年のコンテナセキュリティは単一ツールではなく、**4 レイヤーディフェンス** です。

1. **開発/ビルドゲート** — Trivy (イメージ + IaC) + Checkov + kube-score、CRITICAL/HIGH ならビルド失敗

2. **レジストリ/サプライチェーン** — Cosign 署名、SLSA L3 ビルド、SBOM 添付、Rekor 透明性ログ

3. **クラスター進入** — OPA Gatekeeper または Kyverno による admission ゲート (署名なしイメージ・privileged を拒否)

4. **ランタイム** — Falco/Tetragon/Tracee で行動ベース検知、Sysdig/Wiz のような CNAPP が上位で総合

各段階で一度ずつ防げば、1 段階を突破されても次で捕まえられます。「イメージスキャナ 1 つで十分」な時代は終わりました。小さく始めても構いませんが、4 つのレイヤーをすべて意識して 1〜2 年かけて段階的に整備していくのが 2026 年のコンテナセキュリティの正解です。

References

- Trivy 公式ドキュメント — https://trivy.dev/

- Aqua Trivy GitHub — https://github.com/aquasecurity/trivy

- Anchore Grype — https://github.com/anchore/grype

- Anchore Syft — https://github.com/anchore/syft

- Clair v4 (Quay) — https://github.com/quay/clair

- Snyk Container — https://snyk.io/product/container-vulnerability-management/

- JFrog Xray — https://jfrog.com/xray/

- Sysdig Secure — https://sysdig.com/products/secure/

- Aqua Security — https://www.aquasec.com/

- Wiz — https://www.wiz.io/

- Orca Security — https://orca.security/

- Prisma Cloud (Palo Alto Networks) — https://www.paloaltonetworks.com/prisma/cloud

- CrowdStrike Falcon Cloud Security — https://www.crowdstrike.com/platform/cloud-security/

- Falco (CNCF) — https://falco.org/

- Tetragon (Cilium) — https://tetragon.io/

- Tracee (Aqua) — https://github.com/aquasecurity/tracee

- Kubescape (CNCF) — https://kubescape.io/

- kube-bench — https://github.com/aquasecurity/kube-bench

- kube-score — https://kube-score.com/

- Polaris (Fairwinds) — https://www.fairwinds.com/polaris

- Checkov (Bridgecrew) — https://www.checkov.io/

- OPA Gatekeeper — https://open-policy-agent.github.io/gatekeeper/

- Kyverno — https://kyverno.io/

- Sigstore / Cosign — https://www.sigstore.dev/

- SLSA Framework — https://slsa.dev/

- in-toto — https://in-toto.io/

- CycloneDX (OWASP) — https://cyclonedx.org/

- SPDX (Linux Foundation) — https://spdx.dev/

- Chainguard Images — https://www.chainguard.dev/chainguard-images

- Distroless (Google) — https://github.com/GoogleContainerTools/distroless

- Wolfi OS — https://wolfi.dev/

- NSA/CISA Kubernetes Hardening Guidance — https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3071740/

- CIS Kubernetes Benchmark — https://www.cisecurity.org/benchmark/kubernetes

- NIST SP 800-218 SSDF — https://csrc.nist.gov/projects/ssdf

- EU Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act