Skip to content

✍️ 필사 모드: Container & Cloud-Native Security in 2026 — Trivy vs Grype vs Snyk vs Aikido vs Wiz vs Sysdig vs Tetragon Deep Dive (Shift-Left to Runtime)

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Prologue — "We're running scans" is not security

A 2026 conversation any platform team has at least once.

CISO: "How's our container security?" DevOps lead: "Trivy runs in CI. Every Dockerfile build, every day." CISO: "So how many critical CVEs are in production right now?" DevOps lead: "Uh... we don't track that separately."

This is a common scene in 2026. The scans run, but nobody looks at the results. An image can carry 47 criticals and nobody knows what the actual risk is on our cluster. We don't know which containers reach out to the internet at runtime. We don't know who is holding IAM star permissions. Build-time scans are one signal, and one signal alone doesn't give you a security posture.

The problem is that the tool landscape exploded. Trivy, Grype, and Snyk overlap on three axes alone. Then Aikido enters as "AppSec plus Cloud unified," Wiz and Orca claim to see the whole cloud as a CNAPP, Sysdig and Tetragon claim runtime via eBPF. JFrog Xray sits on the artifact side, Cosign and Sigstore handle signing, SLSA handles supply chain, Wolfi and Chainguard handle distroless. Install them all and you end up with seven contracts and seven dashboards.

This post draws the 2026 May map of container and cloud-native security tools. Where each tool looks, what it misses, how far an OSS-only stack carries you, and what a commercial CNAPP actually adds — from the user perspective, not the marketing page.


1. The terrain — where security tools actually look

Cut by category first. "Container security" is not a single category. It is at least six different problems bundled into one phrase.

StageWhat it measuresOSS toolsCommercial tools
Source / IDECode secrets, 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 / RegistryStored binary plus SBOMOSV, Grype plus HarborJFrog Xray, Aqua
Cloud Posture (CSPM)AWS/GCP/Azure configProwler, ScoutSuiteWiz, Orca, Aikido
Workload (CWPP)In-cluster workloadFalco, TetragonSysdig Secure, Wiz
Identity (CIEM)IAM permission analysis(limited)Wiz, Orca
Data (DSPM)Data location and classification(limited)Wiz, Orca, Cyera
Runtime detectionAnomalous behavior at runtimeFalco, TetragonSysdig Secure, Wiz Runtime
Supply chainBuild provenance and signingSigstore Cosign, SLSA(most platforms integrate)

Key point: no single tool covers every stage. Trivy is dominant for image, IaC, and SBOM, but it cannot see runtime. Wiz is dominant for cloud posture, but it is weak at build time. Sysdig is dominant for runtime, but weak at build time. So you end up with a combination.

The 2026 trend, though, is convergence. Wiz absorbed image scanning, Aikido absorbed CSPM, Snyk added cloud posture. That convergence is the CNAPP (Cloud Native Application Protection Platform) category.


2. Trivy (Aqua Security) — the de-facto OSS standard

If you must pick one container scanning tool to start with in 2026, pick Trivy. Sponsored by Aqua Security but Apache 2.0 licensed, 26k+ GitHub stars, the name that shows up in nearly every CI pipeline.

Version: as of May 2026, v0.60+ line. Quarterly major releases, vulnerability DB updated hourly.

What it scans:

  • Container images (Docker, OCI, containerd)
  • Filesystem (local directories)
  • Git repositories
  • VM images (AMI, VMDK)
  • Kubernetes clusters (in-cluster scan)
  • IaC (Terraform, CloudFormation, Helm, Kustomize, Dockerfile)
  • SBOM generation (SPDX, CycloneDX)
  • Licenses (extract licenses from used libraries)

One-liners.

# Image scan
trivy image alpine:3.19

# Critical/High only, use exit code as a CI gate
trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest

# Generate SBOM (CycloneDX)
trivy image --format cyclonedx --output sbom.json myapp:latest

# Scan the whole cluster
trivy k8s --report summary cluster

# IaC
trivy config ./infra/terraform

Strengths:

  • Fast — single Go binary, no dependencies. Average image scan under 5 seconds.
  • Strong DB — 16+ sources merged: NVD plus GHSA plus Red Hat OVAL plus Alpine secdb plus Debian DSA plus Ubuntu USN plus Wolfi advisory and more.
  • Misconfig built in — 600+ IaC rules, comparable to Checkov.
  • Aqua sponsors it but OSS first — there is a commercial Aqua Platform, but Trivy itself is genuinely OSS.

Weaknesses:

  • Cannot see runtime — build and deploy time only.
  • Cannot see account-level cloud posture (Trivy AWS is limited).
  • False positive handling is manual — silence via a .trivyignore file.

When to use: first tool for almost every team. The core of an OSS stack. Five minutes to add it to CI.


3. Grype + Syft (Anchore) — the SBOM specialists

Syft generates the SBOM and Grype scans that SBOM (or directly an image). Sponsored by Anchore (commercial company) but Apache 2.0 OSS.

# Generate an SBOM with Syft
syft alpine:3.19 -o cyclonedx-json > sbom.json

# Scan the SBOM (not the image) with Grype
grype sbom:./sbom.json

# Direct image scan is also fine
grype alpine:3.19

Versus Trivy:

  • Separated responsibilities — Syft inventories, Grype matches. Small composable units.
  • SBOM-first workflow — a generated SBOM can be re-scanned at later points (when the DB updates, the same image surfaces new CVEs).
  • Deeper language ecosystem support — fine-grained package manager recognition for Java, Python, JavaScript, Go, Ruby, Rust, Swift, .NET.

When to pick Grype/Syft:

  • You want SBOM as a first-class build artifact (SLSA compliance).
  • You need retro-scan of already-registered images.
  • You want a Trivy double-check (different DBs catch different CVEs).

Many teams use Trivy plus Syft — Trivy for scanning, Syft for SBOM production.


4. Snyk — developer-first, sees everything

Snyk sees everything. Code (SAST), Open Source (SCA), Container, IaC. The broadest developer-first security platform in 2026. Free tier (200 tests/month) up to enterprise.

Product line:

  • Snyk Open Source — library CVE plus license. npm, PyPI, Maven, and so on.
  • Snyk Container — image scan plus base image suggestions ("move to Alpine 3.19 and 12 CVEs disappear").
  • Snyk Code — SAST. Semgrep-style.
  • Snyk IaC — Terraform, CloudFormation, K8s manifest misconfig.
  • Snyk AppRisk (launched 2025) — prioritize the above with business context.

Strengths:

  • Developer UX is strong — IDE plugins, GitHub PR checks, automatic fix PRs.
  • Strong vulnerability DB — Snyk's own security team often publishes advisories ahead of NVD.
  • Rich CVE explanations — exploit info, patch paths, workarounds.

Weaknesses and friction:

  • Expensive — developer-seat priced, enterprise contracts easily run into the tens of thousands per year.
  • 2024-2025 licensing controversy — some free-tier users complained about pricing changes; some OSS projects reduced Snyk reliance.
  • Reliance on Snyk's unique advisories — vendor lock-in concern.

Snyk versus Mend (formerly WhiteSource): Mend has long been strong on enterprise SCA. Mend wins on license compliance (legal team friendly). Snyk wins on developer UX and fix automation.

When to use: mid-size to enterprise that values developer experience and automated fix PRs. The free tier is fine for small teams too.


5. Aikido Security — European newcomer, AppSec plus Cloud unified

Aikido is a Belgian-born security startup that started in 2022, raised Series A in 2024 (EUR 17M), and grew quickly in 2025-2026. Position: "one Snyk plus Wiz, cheaper".

Coverage (one SaaS):

  • SAST plus SCA plus Container plus IaC (Snyk territory)
  • Cloud Posture (CSPM, AWS/GCP/Azure)
  • Secret scanning
  • Tool integrations (uses OSS engines like Trivy, Semgrep, OSV under the hood)
  • AI Auto-Fix PRs — generates pull requests for discovered vulnerabilities (the 2025 differentiator)

Strengths:

  • Fast setup — connect GitHub, connect cloud, ten minutes to first results.
  • Pricing explicit and cheap — roughly 40-60% of Snyk/Wiz pricing at comparable tiers.
  • OSS engines plus UX layer — Trivy and Semgrep under the hood, integrated UI plus noise reduction plus AI auto-fix on top.
  • EU GDPR friendly — EU hosting option is first-class.

Weaknesses:

  • Runtime, CIEM, DSPM are weak — not as cloud-deep as Wiz.
  • Enterprise feature gaps — large-org governance and RBAC requirements still maturing.
  • Young company risk — acquisition or strategy shifts are always possible.

When to use: small to mid-size teams. The "Snyk pricing hurts plus we want cloud posture too but Wiz is overkill" intersection. Quickly gaining share in 2026.


6. Wiz — the CNAPP category leader

Wiz started in Israel in 2020 and rapidly took the market with agentless cloud scanning. Valued at 12B+ in 2024, Google announced a 32B acquisition in 2025 (closing completed in 2026). The de-facto leader in the CNAPP (Cloud Native Application Protection Platform) category.

Core idea: snapshot-based agentless. Clone EBS/disk snapshots in your cloud account and scan them via a side channel. No agent deployment means almost no adoption friction — give an IAM role and you are done.

Coverage:

  • CSPM (cloud misconfig)
  • CWPP (workload — VM, container, serverless)
  • CIEM (identity — IAM permission graph)
  • DSPM (data — PII classification inside S3, RDS)
  • Vulnerability (image plus OS)
  • Container and Kubernetes
  • Wiz Code (launched 2024, SAST territory)
  • NHI (Non-Human Identity) (2025-2026 push) — service accounts, API keys, OIDC federation tracked as first-class assets

Strengths:

  • Security Graph — every asset, permission, and vulnerability in a graph DB you can query. Multi-hop questions like "internet-reachable plus critical CVE plus admin IAM."
  • Toxic combinations — not a single CVE but "this combination is dangerous" prioritization. The reason Wiz took the market.
  • Agentless adoption is dramatically lower friction — POC in a week, production in a month.

Weaknesses:

  • Price — enterprise pricing. Not a small-company tool.
  • Runtime detection is weak — agentless by design. So Wiz ships a Runtime Sensor agent separately (launched 2024).
  • Build/CI integration is secondary — Wiz started on the cloud side, not the build side.
  • Post-Google-acquisition uncertainty — in 2026 there is both accelerated GCP integration and concern about AWS/Azure priority.

When to use: multi-cloud enterprise. The selling point is prioritization. Instead of 100 critical CVEs, Wiz shows you 3 with "internet exposure plus critical CVE plus admin IAM" — that is what Wiz sells.


7. Orca Security — the other agentless choice

Orca is in a very similar category to Wiz. Same SideScanning concept, commercialized earlier. They went head to head in 2021-2023, Wiz took the larger share, but Orca remains a strong alternative.

Versus Wiz:

  • Orca started earlier; technical depth is similar.
  • Wiz pulled ahead on sales motion and attack-path visualization.
  • Orca is known to be more flexible on pricing in some enterprise deals.
  • Both are multi-cloud, both are full-stack CNAPP.

When to pick Orca: as a Wiz POC alternative, for pricing leverage, or to avoid GCP-lock concerns post-acquisition.


8. Sysdig Secure / Falco — the runtime standard

Falco is a CNCF graduated project, the de-facto OSS standard for runtime security. Sysdig Secure is the commercial product from the company that built Falco — a production-ready SaaS wrapped around Falco.

Concept: observe kernel events (syscalls, eBPF) in real time and match against rules. Detect behavior like "bash was spawned inside this container."

Example 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 strengths:

  • OSS, CNCF graduated — governance is stable.
  • eBPF plus kernel module — both supported; eBPF-only avoids the module build burden.
  • K8s audit log rules in the same engine — cluster control-plane events too.

Falco weaknesses:

  • Tuning required — out-of-box rules are noisy. SRE has to tune them.
  • Alerts only, response is separate — Falcosidekick handles notification routing; auto-quarantine is a separate integration.
  • Analysis and visualization are minimal — feed into log/metrics systems to make it useful.

Sysdig Secure (commercial) adds:

  • Runtime forensics — point-in-time capture and replay.
  • Rule management UI plus recommended rule sets.
  • Full CNAPP expansion (image scan, cloud posture, IaC) — competing with Wiz on category.
  • Compliance reports (CIS, PCI, HIPAA).

When to use: organizations that require runtime detection (finance, healthcare, government). Or when SOC must see real-time container events. OSS-only means Falco alone; commercial means Sysdig Secure.


9. Tetragon (Cilium / Isovalent) — the eBPF runtime challenger

Tetragon is the runtime security tool from Isovalent (acquired by Cisco in 2024, makers of Cilium). An eBPF-native challenger to Falco. CNCF Sandbox (incubation in progress as of 2024).

Falco versus Tetragon:

DimensionFalcoTetragon
ModelSyscall-based rule matchingeBPF kernel filter plus policy enforcement
ResponseAlert-orientedInline blocking possible (kernel-level enforcement)
GovernanceCNCF graduatedCNCF Sandbox
IntegrationStandaloneNative to Cilium ecosystem
Learning curveRule YAMLTracingPolicy CRD (deeper eBPF understanding helps)

Tetragon's differentiation: not just alerts but kernel-level enforcement — you can block a syscall before it happens. Example: block when execve of /bin/bash is about to spawn inside a container.

When to pick Tetragon: clusters already running Cilium, environments where you need runtime enforcement (blocking, not alerting), teams comfortable with eBPF. 2026 adoption is smaller than Falco but growing fast.


10. JFrog Xray — the artifact side

JFrog Xray is the security module of JFrog Artifactory (the artifact repository). It tracks CVE and license against every binary stored in Artifactory (container images, jars, npm tarballs) on a permanent basis.

Differentiator: repository-centric. It answers "are the things sitting in our Artifactory safe" rather than "did this build pass." When a new CVE drops, every affected stored artifact is surfaced via retro-scan.

When to use: organizations already on JFrog Artifactory. Overlaps with Trivy/Snyk but takes clear ownership of the "stored state" question.


11. Sigstore (Cosign) plus SLSA — the supply chain skeleton

Sigstore is the OSS supply chain signing project under the Linux Foundation. Cosign is its image-signing tool.

# Keyless sign (OIDC-based)
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc...

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

Core ideas:

  • Keyless signing — prove identity via OIDC, Fulcio issues a short-lived certificate, sign with it, record into Rekor (transparency log). No long-term key custody.
  • Reproducible verification — the Rekor log acts as a public ledger.

SLSA (Supply-chain Levels for Software Artifacts): Google-led, OpenSSF-hosted. Defines build-system assurance in four levels.

  • L1: build defined as a script.
  • L2: build service produces provenance.
  • L3: build environment isolated and verifiable.
  • L4: hermetic builds, two-reviewer requirement.

2026 reality: organizations reaching SLSA L3 are still a small group. But Cosign signing plus GHA OIDC plus Rekor logging has become standard for GitHub Actions-based teams. That puts you near SLSA L2.


12. Wolfi / Chainguard — distroless eliminates CVEs

Chainguard started in 2022, Series D in 2025. Core idea: less stuff in the image means fewer CVEs.

  • Wolfi — a security-first Linux distribution (Alpine-style but glibc, an "undistro").
  • Chainguard Images — minimal images built on Wolfi (distroless). cgr.dev/chainguard/python, cgr.dev/chainguard/nginx, and so on.

Example: where the official python:3.12 image carries 12 critical CVEs, cgr.dev/chainguard/python:latest is commonly near zero (Chainguard does daily rebuilds plus fast patches).

Strength: shrink the attack surface itself. Instead of running Trivy to find CVEs, start with an image that has no CVEs in the first place.

Weaknesses:

  • Enterprise images are paid (free tier is the basic :latest lineup only).
  • Debugging is inconvenient (distroless means no sh).
  • Migration cost from existing images.

When to use: when you want to standardize production images on distroless. Finance, government, and healthcare where near-zero CVE counts are mandated.


13. Scanner-versus-coverage matrix

Where each tool sits at a glance.

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

Observations: no tool fills every column. Wiz comes closest, but build/CI integration and NHI are not 100%. What an OSS-only stack misses: cloud posture depth, NHI, DSPM, integrated prioritization.


14. CNAPP category convergence — CSPM + CWPP + CIEM + DSPM

The 2026 big picture: CNAPP (Cloud Native Application Protection Platform). A category Gartner defined to unify:

  • CSPM (Cloud Security Posture Management) — cloud misconfig.
  • CWPP (Cloud Workload Protection Platform) — VM, container, serverless protection.
  • CIEM (Cloud Infrastructure Entitlement Management) — IAM permissions.
  • DSPM (Data Security Posture Management) — data location, classification, and access.

In 2025-2026 it absorbed Vulnerability Management too. And NHI (Non-Human Identity) — governing service accounts, API keys, and OIDC federation like human identities — emerged as a new category. Wiz is ahead here.

Why convergence: security teams cannot watch seven dashboards. And toxic combination prioritization — "reachable critical CVE plus admin permission plus internet exposure" — only works on a single graph. Separated tools cannot produce that graph.

Counterpoint: a single giant platform is lock-in. So a hybrid pattern is growing — keep the OSS stack as the engines, buy only the integrated UI on top (the Aikido model, or a homegrown SOAR).


15. Shift-Left versus Runtime — the never-ending debate

Shift-Left (catch at build time):

  • Cheapest — the developer fixes it in the PR.
  • Noisy — not every CVE is a real risk.
  • Lacks reachability and exploitability info.

Runtime (look only at what actually runs):

  • Signal is real — only containers that actually run.
  • But late — already in production.
  • Agent overhead plus performance impact.

2026 consensus: do both. But the resource allocation differs.

  • Shift-left is "basic hygiene." Every PR blocks criticals.
  • Runtime is the "reachability filter." Of 100 critical CVEs, prioritize the 27 whose libraries actually load in production.

Tying these two signals together is the biggest value a CNAPP delivers — the eBPF runtime tells you "this package is actually imported," and you mark only those 27 as critical-priority in the build-time CVE list. The other 73 are critical but lower priority. Wiz, Sysdig, and Aikido all pushed this in 2025-2026.


16. AI-AppSec — the auto-fix PR era

A new 2025-2026 category: AI finds the vulnerability and ships a patched PR.

  • Aikido AI Auto-Fix — auto-generates dependency-upgrade PRs for discovered CVEs.
  • Snyk DeepCode AI — code-fix suggestions for SAST findings.
  • GitHub Dependabot plus Copilot Autofix (GA in 2024) — Dependabot for dependency PRs, Copilot Autofix for SAST-finding code patches.
  • Endor Labs — reachability analysis filters real risk, then ships fix PRs on top.

Reality:

  • Dependency upgrades automate well — one or two line changes.
  • Code fixes still need a human reviewer — SAST findings need context.
  • False positive rate is still around 50% — you do not auto-merge every PR.

Value: review time. Of 50 fix PRs, 30 merge instantly and 20 get a human look.


17. Decision framework — what should our team install

Walk the questions and narrow it down.

Q1. How big is the team?

  • 5-20 people — OSS only is enough. Trivy plus Falco plus Cosign plus Dependabot. 0 dollars/year.
  • 20-100 people — Aikido or Snyk plus Trivy. One SaaS plus one OSS. 10k-50k dollars/year.
  • 100+ / enterprise — Wiz or Orca plus Sysdig plus Snyk/Aikido. CNAPP plus runtime plus dev. 100k+ dollars/year.

Q2. Which category is your biggest risk?

  • Build/supply chain — Trivy plus Cosign plus Chainguard.
  • Cloud misconfig — Wiz/Orca/Aikido CSPM.
  • Runtime intrusion — Sysdig Secure or Falco plus SIEM.
  • Permission sprawl (IAM star) — Wiz/Orca CIEM.

Q3. How far does OSS-only carry you?

  • Doable: image scan, IaC, SBOM, signing, runtime alerting (Falco), partial CSPM (Prowler).
  • Hard: graph-based prioritization, NHI governance, DSPM, integrated dashboard.
  • You can pass SOC2/ISO 27001 with OSS alone. You just pay the operational cost in people.

Q4. How not to fall for marketing:

  • "CNAPP" labels do not all do the same thing — draw the matrix yourself.
  • In a POC, throw 100 real CVEs from your environment at three tools and compare noise/accuracy.
  • Pricing is per developer, per asset, per workload — normalize before comparing.
  • "AI auto-fix" claims — compare marketing demos to actual merge rates in your codebase.

Epilogue — "who reads the scan results" is the answer

One-sentence summary: operations make security, not tools.

There is no shortage of 2026 container security tools. Trivy in five minutes for free, Aikido in ten minutes including cloud, Wiz in a month for the whole enterprise. The real question is who looks at the output every week and what decisions they make. Install all the tools and let alerts pile up in Slack with no owner — the security level is zero.

Seven traits of a good container security program:

  1. Start with one tool — Trivy as a CI gate blocking criticals.
  2. One runtime line — Falco or Tetragon, one alert channel.
  3. Signing plus provenance — Cosign plus Rekor, free with GHA OIDC.
  4. Base image standard — Chainguard or distroless. Reject non-standard new images.
  5. Quarterly trailing review — a human looks at what the tools missed.
  6. Prioritization rules — only toxic combos like "reachable plus internet-exposed plus admin."
  7. Auto PR plus human review — Dependabot/Aikido fix PRs, a human merges.

These seven matter more than which tool you pick. Install Wiz without these seven and you still miss things. Run only Trivy with these seven and you catch 95%.

12-item checklist

  1. Image scan in CI as a critical gate?
  2. Base-image standard (distroless/Wolfi)?
  3. IaC scan at PR time?
  4. SBOM saved as a build artifact?
  5. Image signing (Cosign) enforced in production?
  6. Runtime detection deployed in the cluster (Falco/Sysdig/Tetragon)?
  7. Cloud posture scanned daily (Prowler/Wiz/Aikido)?
  8. Externally-reachable asset inventory exists?
  9. Critical CVE alerts read every week by someone?
  10. IAM star permissions detected automatically?
  11. Secret scanning at git-push time?
  12. SLSA L2-class provenance (GHA OIDC plus Cosign plus Rekor)?

10 anti-patterns

  1. Nobody reads Trivy output — scans just run.
  2. Block every critical — real risk drowns in noise.
  3. Build scans without runtime — no reachability signal.
  4. Three CNAPP POCs in parallel — a year stuck in the mud.
  5. Generate SBOMs without verifying — ritual.
  6. Sign with Cosign but no verification policy — signatures block nothing.
  7. Free choice of base image every time — no distroless standard.
  8. Alerts without prioritization — paralyzed by 100 criticals.
  9. All shift-left, zero runtime — blind after build.
  10. Adopt commercial, drop OSS entirely — the moment you remove Trivy from CI you lose a signal.

Up next

Possible next posts: Wiz Security Graph deep dive — how toxic-combination prioritization works, Sigstore plus GHA OIDC plus SLSA L2 in practice, Falco versus Tetragon — actual operational differences in rule authoring.

"Tools do not make security. Who reads the output every week and what they fix does."

— Container & cloud-native security 2026, end.


References

현재 단락 (1/324)

A 2026 conversation any platform team has at least once.

작성 글자: 0원문 글자: 23,815작성 단락: 0/324