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

プロローグ — 「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 つの異なる問題が一語にまとまっている。

要点: 一つの 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（Docker, OCI, containerd）
• filesystem（ローカル directory）
• Git repository
• VM image（AMI, VMDK）
• Kubernetes cluster（in-cluster scan）
• IaC（Terraform, CloudFormation, Helm, Kustomize, Dockerfile）
• SBOM 生成（SPDX, CycloneDX）
• license（使用 library の license 抽出）

一行使用法.

# 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

強み:

• 速い — Go 単一 binary、依存なし。image scan 平均 5 秒以下。
• DB が良い — NVD + GHSA + Red Hat OVAL + Alpine secdb + Debian DSA + Ubuntu USN + Wolfi advisory など 16+ ソース統合。
• misconfig 同梱 — IaC rule 600+（Checkov 水準）。
• Aqua が後援するが OSS 優先 — 商用 Aqua Platform はあるが Trivy 自体は本物の OSS。

弱み:

• runtime は見えない — build/deploy 時点のみ。
• cloud account 単位の posture は見えない（Trivy AWS は限定的）。
• false positive 処理が手動 — .trivyignore ファイルで黙音化。

いつ使うか: ほぼ全 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 との違い:

• 責任の分離 — Syft は inventory のみ、Grype は matching のみ。小さい単位の composable。
• SBOM-first workflow — 一度作った SBOM を後の時点で再 scan できる（DB が更新されれば同じ image の新規 CVE を見つける）。
• 言語生態系の支援が深い — Java, Python, JavaScript, Go, Ruby, Rust, Swift, .NET など、package manager 別の認識が細かい。

Grype/Syft をいつ使うか:

• SBOM を build artifact として正式管理したいとき（SLSA 準拠）
• 登録済み image の retro-scan が必要なとき
• Trivy と double-check（異なる DB が異なる CVE を捕まえる）

多くの 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 Open Source — library CVE + license。npm/PyPI/Maven など。
• Snyk Container — image scan + base image 推奨（「Alpine 3.19 に移れば CVE 12 個消える」）。
• Snyk Code — SAST。Semgrep style。
• Snyk IaC — Terraform/CloudFormation/K8s manifest の misconfig。
• Snyk AppRisk（2025 年リリース）— 上記結果を business context で優先順位化。

強み:

• 開発者 UX が良い — IDE plugin、GitHub PR check、自動 fix PR。
• vulnerability DB が良い — Snyk 自身の security team が NVD より早く advisory を出す。
• CVE 説明が豊富 — exploit 情報、patch 経路、workaround。

弱み/論点:

• 値段が高い — 開発者数ベース、enterprise は年 数万ドルを軽く超える。
• 2024-2025 年の data license 論争 — Snyk 一部の free plan 利用者が値上げに不満、一部 OSS project が Snyk 依存を減らした。
• 独自 DB の unique advisory 依存 — vendor lock-in 意識。

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 で）:

• SAST + SCA + Container + IaC（Snyk 領域）
• Cloud Posture（CSPM、AWS/GCP/Azure）
• Secret scan
• 使用 tool 統合（Trivy・Semgrep・OSV など OSS engine を内部で使う）
• AI Auto-Fix PR — 発見された脆弱性に対して自動的に PR を生成して送る（2025 年の差別化機能）

強み:

• 素早い setup — GitHub 接続 → cloud connect → 10 分で初結果。
• 値段が明示的で安い — Snyk/Wiz 比 4060% 水準の価格 position。
• OSS engine + UX 層 — 内部は Trivy/Semgrep のような OSS、上は統合 UI/noise 削減/AI auto-fix。
• 欧州 GDPR 親和 — EU hosting option が最初から明示。

弱み:

• runtime / CIEM / DSPM は弱い — Wiz ほど cloud-deep ではない。
• enterprise feature gap — 大組織の governance/RBAC 要求はまだ埋まっている途中。
• 新興会社 risk — 買収/会社変化の可能性は常にある。

いつ使うか: 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:

• CSPM（cloud misconfig）
• CWPP（workload — VM, container, serverless）
• CIEM（identity — IAM 権限 graph）
• DSPM（data — S3/RDS 内の PII 分類）
• Vulnerability（image + OS）
• Container/K8s
• Wiz Code（2024 年リリース、SAST 領域）
• NHI（Non-Human Identity）（2025-2026 強化領域）— service account, API key, OIDC federation を asset のように追跡

強み:

• Security Graph — 全 asset/権限/脆弱性を graph DB に入れて query。「外部 internet から到達可能 + critical CVE + admin IAM 権限」のような multi-hop query。
• Toxic combination — 単一 CVE ではなく「この組み合わせが危険」優先順位化。これが Wiz が市場を取った理由。
• agentless 導入の圧倒的な摩擦削減 — POC 1 週、production 1 ヶ月。

弱み:

• 値段 — enterprise 価格。小会社が使える tool ではない。
• runtime detection は弱い — agentless なので。だから Wiz Runtime Sensor（agent）を別途入れる（2024 年リリース）。
• build/CI 段階の統合は二次 — Wiz は cloud 側から始まり、build 側が強みではない。
• Google 買収後の変化 — 2026 年現時点で GCP 統合の加速 vs AWS/Azure 優先順位の懸念が同時にある。

いつ使うか: 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 が sales motion と attack-path 可視化で前に出た。
• Orca は一部 enterprise で Wiz より価格が柔軟と言われている。
• 両方 multi-cloud、両方 CNAPP フルスタック。

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 強み:

• OSS、CNCF graduated — governance 安定。
• eBPF + kernel module — 両方 support、eBPF のみで module build 負担なし。
• K8s audit log rule も同じ engine で — cluster control-plane event も。

Falco 弱み:

• tuning が必要 — out-of-box rule は noise が多い。SRE が rule を調整する必要。
• alert のみ、応答は別 — Falcosidekick で通知配信はするが自動隔離は別統合。
• 解析/可視化は薄い — log/metric system に入れて使い物になる。

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

• runtime forensics — 時点 capture/replay。
• rule 管理 UI + 推奨 rule set。
• CNAPP フルスタックへの拡張（image scan, cloud posture, IaC）— Wiz と category 競争。
• compliance report（CIS, PCI, HIPAA）。

いつ使うか: 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:

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:

• keyless 署名 — OIDC で身元証明 → Fulcio が短命 certificate 発行 → 署名 → Rekor（transparency log）に記録。key 保管負担なし。
• 再現可能な検証 — Rekor log が公開 ledger のように動作。

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

• L1: build が script で定義。
• L2: build service が provenance を生成。
• L3: build 環境が分離され検証可能。
• L4: hermetic build、2 名 reviewer。

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 も減る。

• Wolfi — security-first の Linux distribution（Alpine style だが glibc、「undistro」）。
• Chainguard Images — Wolfi ベースの minimal image（distroless）。cgr.dev/chainguard/python, cgr.dev/chainguard/nginx など。

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

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

弱み:

• enterprise image は有料（無料は :latest 基本 lineup のみ）。
• debug が不便（distroless なので sh もない）。
• 既存 image からの migration コスト。

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

13 章 · scanner vs coverage matrix

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

観察: 一つの 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 で、次を統合:

• CSPM（Cloud Security Posture Management）— cloud misconfig。
• CWPP（Cloud Workload Protection Platform）— VM/container/serverless 保護。
• CIEM（Cloud Infrastructure Entitlement Management）— IAM 権限。
• DSPM（Data Security Posture Management）— data の場所・分類・access。

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 時点で捕まえる）:

• 最も安い — 開発者が PR で直す。
• noise が多い — 全 CVE が実際の risk ではない。
• 到達可能性・exploit 可能性の情報が足りない。

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

• signal が本物 — 実際に動く container だけ。
• しかし遅い — すでに production。
• agent 負担 + 性能影響。

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

• Shift-left は「基本衛生」。全 PR で critical を阻止。
• Runtime は「到達可能性 filter」。critical 100 個のうち実際に production で load される library 27 個だけ優先順位化。

この 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 まで送る。

• Aikido AI Auto-Fix — 発見された CVE に対して依存関係 upgrade PR を自動生成。
• Snyk DeepCode AI — SAST 発見に対する code fix 提案。
• GitHub Dependabot + Copilot Autofix（2024 年 GA）— Dependabot が依存関係 PR、Copilot Autofix が SAST 発見の code patch。
• Endor Labs — reachability analysis で本物の risk のみ、その上に fix PR。

現実:

• 依存関係 upgrade は自動化が良くできる — 1~2 行変更。
• code fix はまだ誰かが review する — SAST 発見は context が多く必要。
• false positive 比率 は依然 50% 近傍 — 全 auto PR を受けるわけではない。

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

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

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

Q1. team の規模は?

• 5~20 人 — OSS のみで十分。Trivy + Falco + Cosign + Dependabot。年 0 ドル。
• 20~100 人 — Aikido または Snyk + Trivy。1 個の SaaS + 1 個の OSS。年 1~5 万ドル。
• 100 人+ / enterprise — Wiz または Orca + Sysdig + Snyk/Aikido。CNAPP + runtime + dev。年 10 万ドル+。

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

• build/supply chain — Trivy + Cosign + Chainguard。
• cloud misconfig — Wiz/Orca/Aikido CSPM。
• runtime 侵入 — Sysdig Secure または Falco + SIEM。
• 権限暴走（IAM *） — Wiz/Orca CIEM。

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

• 可能: image scan、IaC、SBOM、署名、runtime alert（Falco）、一部 CSPM（Prowler）。
• 難しい: graph ベース優先順位化、NHI governance、DSPM、統合 dashboard。
• OSS のみで SOC2/ISO 27001 通過可能。ただし運用負担は人で埋める。

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

• 「CNAPP」label が付いた tool が全部同じ機能を持つわけではない — matrix を自分で描く。
• POC で 自分の環境の本物の CVE 100 個 を tool 3 個に投げて noise/精度を比較。
• 価格は 開発者数 / asset 数 / workload 数 など単位ごとに違う — 比較時に正規化。
• 「AI 自動 fix」は marketing 資料の demo と我々の codebase の実際の PR merge 率を比較。

エピローグ —「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

• Trivy — Aqua Security
• Trivy GitHub — aquasecurity/trivy
• Trivy Documentation
• Grype — Anchore
• Syft — SBOM generator
• Snyk — Developer Security Platform
• Snyk Open Source
• Snyk Container
• Aikido Security
• Aikido AI AutoFix announcement
• Wiz — Cloud Security Platform
• Wiz Security Graph
• Google to acquire Wiz — 2024 announcement
• Orca Security
• Sysdig Secure
• Falco — CNCF graduated
• Falco GitHub — falcosecurity/falco
• Tetragon — Isovalent/Cilium
• Tetragon GitHub — cilium/tetragon
• JFrog Xray
• Mend — formerly WhiteSource
• Sigstore
• Cosign GitHub — sigstore/cosign
• Rekor — transparency log
• SLSA — Supply-chain Levels for Software Artifacts
• Chainguard — secure base images
• Wolfi — undistro Linux
• Prowler — OSS CSPM
• OSV.dev — Open Source Vulnerabilities
• OpenSSF — Open Source Security Foundation
• Gartner — CNAPP definition
• GitHub Copilot Autofix
• Endor Labs — reachability analysis
• CNCF Landscape — Security & Compliance