LabHub

ブログ

コンテナ & クラウドネイティブセキュリティ 2026 — Trivy・Grype・Snyk・Aikido・Wiz・Sysdig・Tetragon 徹底比較（Shift-Left から Runtime まで）

2026-05-14 · 31 分で読めます · #container-security#trivy#snyk#aikido#wiz#sysdig#cnapp#sigstore#sbom#japanese

한국어English日本語

プロローグ — 「scan は回ってます」は security ではない

2026 年、どの platform team でも一度はある会話。

CISO「コンテナ security の状況は?」 DevOps リード「Trivy が CI で回ってます。毎日 Dockerfile build のたびに。」 CISO「で、production に critical CVE は何個ある?」 DevOps リード「うーん…そこは別に見てないんですよ。」

これが 2026 年でもよくある光景だ。scan は回っているが、誰も結果を見ていない。image に critical が 47 個あっても、それが我々の cluster で実際にどんな risk なのかわからない。runtime でどの container が外部に call を出しているかも知らない。誰が IAM * の権限を持っているかも知らない。build 時の scan は signal の一つにすぎず、それだけでは security posture はできない。

問題は、tool が増えすぎたことだ。Trivy・Grype・Snyk だけでも 3 つが被る。そこに Aikido が「AppSec + Cloud 統合」で乗り込み、Wiz・Orca は CNAPP で cloud 全体を見ると言い、Sysdig・Tetragon は eBPF で runtime を見ると言う。JFrog Xray は artifact 側、Cosign・Sigstore は署名、SLSA は supply chain、Wolfi/Chainguard は distroless。全部入れたら 7 社の契約と 7 つの dashboard ができる。

この記事は 2026 年 5 月時点のコンテナ & クラウドネイティブセキュリティ tool の地図を描く。各 tool が どこ を見て 何を 見逃すか、OSS-only stack でどこまで行けるか、商用 CNAPP が本当に追加する価値は何か — marketing ページではなく、実ユーザー視点で。

1 章 · 地形図 — security tool はどこを見るか

まず category を切る。「コンテナセキュリティ」という単一 category はない。少なくとも 6 つの異なる問題が一語にまとまっている。

段階測定対象OSS tool商用 tool
Source / IDEcode 秘密、SASTSemgrep, GitleaksSnyk Code, Aikido
Dependency (OSS)library CVETrivy, Grype, OSV-ScannerSnyk Open Source, Mend
Container Imageimage layer CVETrivy, Grype, SyftSnyk Container, Aikido
IaC / K8s manifestmisconfigTrivy, Checkov, KyvernoSnyk IaC, Aikido
Artifact / Registry保存 binary + SBOMOSV, Grype + HarborJFrog Xray, Aqua
Cloud Posture (CSPM)AWS/GCP/Azure 設定Prowler, ScoutSuiteWiz, Orca, Aikido
Workload (CWPP)cluster 内 workloadFalco, TetragonSysdig Secure, Wiz
Identity (CIEM)IAM 権限解析(限定的)Wiz, Orca
Data (DSPM)data の場所と分類(限定的)Wiz, Orca, Cyera
Runtime detection実行中の異常行動Falco, TetragonSysdig Secure, Wiz Runtime
Supply chainbuild 出所と署名Sigstore Cosign, SLSA(多くの platform が統合)

要点: 一つの tool が全段階を見るわけではない。Trivy は image/IaC/SBOM で最強だが runtime は見えない。Wiz は cloud posture で最強だが image build 段階は弱い。Sysdig は runtime で最強だが build 段階は弱い。だから 組み合わせ が必要になる。

ただし 2026 年の trend は 収束 だ。Wiz は image scan を吸収し、Aikido は CSPM を吸収し、Snyk は cloud posture を足した。この収束が CNAPP（Cloud Native Application Protection Platform）category だ。

2 章 · Trivy（Aqua Security）— OSS の事実上の標準

2026 年のコンテナ scan の最初の tool を一つだけ選ぶなら Trivy だ。Aqua Security が後援するが Apache 2.0 license、GitHub star 26k+、事実上ほぼ全ての CI で一度は出会う名前。

version: 2026 年 5 月時点で v0.60+ ライン。四半期 major release、vulnerability DB は毎時更新。

scan 対象:

一行使用法.

# image scan
trivy image alpine:3.19

# Critical/High のみ、終了 code で CI gate
trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest

# SBOM 生成（CycloneDX）
trivy image --format cyclonedx --output sbom.json myapp:latest

# K8s cluster 全体 scan
trivy k8s --report summary cluster

# IaC
trivy config ./infra/terraform

強み:

弱み:

いつ使うか: ほぼ全 team の最初の tool。OSS stack の core。ほぼ全 CI に 5 分で着く。

3 章 · Grype + Syft（Anchore）— SBOM 専門家

Syft が SBOM を作り、Grype がその SBOM（または image）を scan する。Anchore（商用会社）が後援するが Apache 2.0 OSS。

# Syft で SBOM 生成
syft alpine:3.19 -o cyclonedx-json > sbom.json

# Grype で SBOM scan（image ではなく SBOM を入力）
grype sbom:./sbom.json

# 直接 image scan も可能
grype alpine:3.19

Trivy との違い:

Grype/Syft をいつ使うか:

多くの team が Trivy + Syft の組み合わせを使う — Trivy は scan、Syft は SBOM 産出。

4 章 · Snyk — developer-first、全部見える

Snyk は全部見える。Code（SAST）、Open Source（SCA）、Container、IaC。2026 年時点で最も広い developer-first security platform。free tier（月 200 件）から enterprise まで。

製品ライン:

強み:

弱み/論点:

Snyk vs Mend（旧 WhiteSource）: Mend は enterprise SCA の古参の強者。license compliance（法務 team 親和）では Mend が強い。開発者 UX と fix automation は Snyk が強い。

いつ使うか: 開発者 experience と自動 fix PR を重視する mid-size~enterprise。free tier で小 team の開始にも良い。

5 章 · Aikido Security — 欧州出身の新鋭、AppSec + Cloud 統合

Aikido は 2022 年にベルギーで始まった security startup で、2024 年 Series A（17M EUR）、2025-2026 年に急成長。position は「Snyk + Wiz を一つに、安く」。

coverage（一つの SaaS で）:

強み:

弱み:

いつ使うか: small~mid-size team、「Snyk の値段が痛い」「Wiz までは過剰だが cloud も見たい」— この交差点。2026 年に急速に share を取っている。

6 章 · Wiz — CNAPP category リーダー

Wiz は 2020 年にイスラエルで始まり、agentless cloud scanning で素早く市場を取った。2024 年 valuation 12B+、2025 年に Google が 32B での買収を発表（2026 年 closing 完了）。CNAPP（Cloud Native Application Protection Platform）category の事実上の標準。

core concept: snapshot ベースの agentless。cloud account の EBS/Disk snapshot をクローンして side channel で scan する。agent 配備がないので導入の摩擦がほぼゼロ — IAM role 一つ渡せば終わり。

coverage:

強み:

弱み:

いつ使うか: multi-cloud enterprise。positioning の core は「優先順位化」。100 個の critical CVE よりも「外部 exposure + critical + admin 権限」3 個を見せるのが Wiz が売る価値。

7 章 · Orca Security — agentless のもう一つの選択肢

Orca は Wiz と非常に似た category。同じ SideScanning concept を先に商用化。2021-2023 年は Wiz と正面競争、市場は Wiz がより大きく取ったが、依然として強力な代替。

vs Wiz:

Orca を検討するとき: Wiz POC の代替、価格交渉力、または Wiz 買収後の GCP 依存を避けたいとき。

8 章 · Sysdig Secure / Falco — runtime の標準

Falco は CNCF graduated project、runtime security の事実上の OSS 標準。Sysdig Secure は Falco を作った会社の商用製品 — Falco を production-ready に包んだ SaaS。

concept: kernel event（syscall, eBPF）をリアルタイムで見て rule に match。「container 内で bash が spawn された」のような行動を捕える。

rule 例（Falco YAML）.

- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name container=%container.name shell=%proc.name)
  priority: NOTICE

Falco 強み:

Falco 弱み:

Sysdig Secure（商用）の追加価値:

いつ使うか: runtime detection が必須の組織（金融・healthcare・政府）。または SOC が container cluster のリアルタイム event を見る必要があるとき。OSS stack なら Falco 単独、商用なら Sysdig Secure。

9 章 · Tetragon（Cilium / Isovalent）— eBPF runtime の挑戦者

Tetragon は Cilium を作った Isovalent（2024 年 Cisco 買収）の runtime security tool。Falco の eBPF-native 競合。CNCF Sandbox（2024 年に incubation 進行中）。

Falco vs Tetragon:

次元FalcoTetragon
modelsyscall ベースの rule matchingeBPF kernel filter + policy enforcement
応答alert 中心inline 遮断可能（kernel-level enforcement）
governanceCNCF graduatedCNCF Sandbox
統合独立Cilium 生態系と native
学習曲線rule YAMLTracingPolicy CRD（やや深い eBPF 理解が必要）

Tetragon の差別化: 単純 alert ではなく kernel-level enforcement — 特定 syscall が起こる前に遮断できる。例: container 内で execve で /bin/bash が spawn されようとするとき遮断。

Tetragon を選ぶとき: 既に Cilium を使っている cluster、runtime enforcement（alert ではなく遮断）が必要な現場、eBPF に慣れた team。2026 年の採用は Falco より小さいが急速に増えている。

10 章 · JFrog Xray — artifact 側

JFrog Xray は JFrog Artifactory（artifact 倉庫）の security module。保存された全 binary（container image, jar, npm tarball など）に対して CVE/license を永続的に追跡。

差別点: 倉庫中心。build/deploy の流れではなく「今 Artifactory にあるものが安全か」に答える。新 CVE が公開されると影響を受ける全保存 artifact が retro-scan で表示。

いつ使うか: 既に JFrog Artifactory を使っている組織。Trivy/Snyk と被るが「保存時点」の責任を明確に取る。

11 章 · Sigstore（Cosign）+ SLSA — supply chain の骨格

Sigstore は OSS supply chain 署名 project（Linux Foundation）。Cosign はそのうちの image 署名 tool。

# keyless 署名（OIDC ベース）
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc...

# 検証
cosign verify --certificate-identity-regexp '.*@myorg.com$' \
  --certificate-oidc-issuer https://accounts.google.com \
  ghcr.io/myorg/myapp@sha256:abc...

core concept:

SLSA（Supply-chain Levels for Software Artifacts）: Google 主導、OpenSSF host。build system の保証水準を 1~4 level で定義。

2026 年の現実: SLSA L3 に到達する組織は依然として少数。しかし Cosign 署名 + GHA OIDC + Rekor 記録 が GitHub Actions ベース team の標準になりつつある。これが SLSA L2 近傍だ。

12 章 · Wolfi / Chainguard — distroless で CVE を無くす

Chainguard は 2022 年に始まり、2025 年 Series D。core idea: image に入れるものを減らせば CVE も減る。

例: python:3.12 公式 image に critical CVE が 12 個あるなら、cgr.dev/chainguard/python:latest には 0 個近いのが普通（Chainguard が daily rebuild + 速い patch）。

強み: 攻撃表面そのものを減らす。Trivy を回して CVE を探すのではなく、最初から CVE がない image で始める。

弱み:

いつ使うか: production image の標準を distroless にしたいとき。金融・政府・healthcare のように CVE ゼロに近く維持が強制される現場。

13 章 · scanner vs coverage matrix

tool の位置を一目で見る表。

toolImageCodeOSS depIaCCloud postureRuntimeNHIDSPMSBOMOSS
TrivyO-OO(partial)---Oyes
Grype + SyftO-O-----Oyes
SnykOOOO(Cloud add-on)---Ono
AikidoOOOOO-(partial)-Ono
WizOOOOO(sensor)OO-no
OrcaOOOOO-OO-no
Sysdig SecureO-OOOO--O(Falco part)
Falco-----O---yes
Tetragon-----O---yes
JFrog XrayO-O-----Ono
Cosign(sign)-------(verify)yes
Chainguard(distro)-------Ono

観察: 一つの tool が全 column を埋めることはない。Wiz が最も近いが build/CI 統合と NHI は 100% ではない。OSS-only で行くと抜けるもの: cloud posture、NHI、DSPM、統合された優先順位化。

14 章 · CNAPP category 収束 — CSPM + CWPP + CIEM + DSPM

2026 年の big picture: CNAPP（Cloud Native Application Protection Platform）。Gartner が定義した category で、次を統合:

2025-2026 年に Vulnerability Management まで吸収。そして NHI（Non-Human Identity）— service account, API key, OIDC federation を人 ID のように governance — が新 category として浮上。Wiz がこの領域で先行。

なぜ収束するか: security team は 7 個の dashboard を見られない。そして「到達可能な critical CVE + admin 権限 + 外部 exposure」のような toxic combination 優先順位化は単一 graph 上でしかできない。tool が分かれると その graph が作れない。

反論: 巨大単一 platform は lock-in。だから OSS stack を維持して統合 UI だけ買う形（Aikido model または自前 SOAR）も増えている。

15 章 · Shift-Left vs Runtime — 終わらない議論

Shift-Left（build 時点で捕まえる）:

Runtime（実際に動くものだけ見る）:

2026 年の合意: 両方やる。しかし 資源配分 が違う。

この 2 つの signal を結ぶのが CNAPP の最大の価値 — eBPF runtime が「この package は実際に import された」と教えてくれれば、build-time CVE list でその 27 個だけを critical で表示。残り 73 個は critical だが優先順位低。これが Wiz・Sysdig・Aikido が 2025-2026 年に揃って押している方向。

16 章 · AI-AppSec — auto-fix PR の時代

2025-2026 年の新 category: AI が脆弱性を見つけて PR で patch まで送る。

現実:

価値: review 時間短縮。50 個の fix PR のうち 30 個は即 merge、20 個は人が見る。

17 章 · 判断 framework — 我々の team は何を入れるか

質問をたどって答えを絞る。

Q1. team の規模は?

Q2. どの category が我々の最大 risk か?

Q3. OSS-only でどこまで行けるか?

Q4. marketing に騙されない方法:

エピローグ —「scan 結果を誰が見るか」が答えだ

この記事の一文要約: tool ではなく運用が security を作る。

2026 年のコンテナ security tool は溢れている。Trivy 無料で 5 分で setup、Aikido 10 分で cloud まで接続、Wiz 1 ヶ月で enterprise 全体が見える。問題は その結果を毎週誰が見て、何を決めるか だ。tool を入れても alert が Slack channel に積まれ、誰も見ないなら security はゼロだ。

良いコンテナ security program の 7 つ:

  1. 単一 tool で開始 — Trivy CI gate、critical のみ阻止。
  2. runtime 1 行 — Falco または Tetragon、channel 一つで alert。
  3. 署名 + provenance — Cosign + Rekor、GHA OIDC で無料。
  4. base image 標準 — Chainguard または distroless。新 image は標準外を拒否。
  5. 四半期ごとの後追い review — tool が見逃したものを人が見る。
  6. 優先順位化 rule — 「到達可能 + 外部 exposure + admin 権限」のような toxic combo のみ。
  7. 自動 PR + 人 review — Dependabot/Aikido fix PR、人が merge。

この 7 個が tool の何を選ぶかより重要だ。Wiz を入れてもこの 7 個がなければ捕まえられない。Trivy 一つでもこの 7 個があれば 95% 捕まえる。

12 項目 checklist

  1. CI に image scan が付いているか（critical gate）?
  2. base image 標準があるか（distroless/Wolfi）?
  3. IaC scan が PR 段階にあるか?
  4. SBOM が build artifact として保存されるか?
  5. image 署名（Cosign）が production で強制されるか?
  6. runtime detection tool が cluster にあるか（Falco/Sysdig/Tetragon）?
  7. cloud posture が毎日 scan されるか（Prowler/Wiz/Aikido）?
  8. 外部到達可能 asset の inventory があるか?
  9. critical CVE alert を毎週誰が見るか?
  10. IAM * 権限が自動検出されるか?
  11. secret scan が git push 段階にあるか?
  12. SLSA L2 近傍の provenance があるか（GHA OIDC + Cosign + Rekor）?

anti-pattern 10 個

  1. Trivy 結果を誰も見ない — scan だけ回る。
  2. 全 critical を遮断 — noise に埋もれて本物の risk が見えない。
  3. runtime なしで build scan のみ — 到達可能性情報がない。
  4. CNAPP tool 3 個同時導入 — POC 泥沼に 1 年。
  5. SBOM を生成するが検証しない — 儀式。
  6. Cosign 署名はするが検証 policy なし — 署名が何も阻止しない。
  7. base image を毎回自由に選ぶ — distroless 標準の不在。
  8. alert だけ見て優先順位化なし — 100 個 critical で麻痺。
  9. shift-left に全資源、runtime ゼロ — build 通過後を見れない。
  10. 商用 tool を入れたら OSS を全部捨てる — Trivy を CI から外した瞬間に signal が減る。

次回予告

次回候補: Wiz Security Graph を深掘り — toxic combination 優先順位化の原理、Sigstore + GitHub Actions OIDC で SLSA L2 を作る実践、Falco vs Tetragon — rule 作成と運用の実際の違い。

「tool が security を作るのではない。毎週その結果を誰が見て何を直すかが security を作る」

— コンテナ & クラウドネイティブセキュリティ 2026、終わり。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます