DEV Community

Cover image for Container Security in 2026: Why One Free Scanner Beats a $32B Acquisition on Half the Job
Moksh Gupta
Moksh Gupta

Posted on Originally published at devtoollab.com

Container Security in 2026: Why One Free Scanner Beats a $32B Acquisition on Half the Job

Every container image is somebody else's OS packages zipped into layers, and whatever base image you picked last quarter is still shipping today, unchanged, every time CI runs. That's the uncomfortable part of container security: it's never a one-time check, because the image you scanned yesterday isn't the image that ships tomorrow.

Here's a number that makes the point. On September 2, 2026, running Trivy against node:18-alpine turned up 17 HIGH and CRITICAL OS vulnerabilities. Running it against alpine:3.20 turned up zero. Same scanner, same afternoon, one line changed in a Dockerfile. Meanwhile Google closed its $32 billion purchase of Wiz back in March 2026, the biggest acquisition in company history, buying a platform that solves a problem overlapping heavily with what that free 37,000-star binary just did in under a minute. I wrote up the full comparison on DevToolLab, including every tool's current pricing and license.

Both of those facts are true at once because "container security" isn't one job. It's three.

Three jobs, not one

Build-time scanning looks at an image or manifest and checks it against a CVE database. Fast, runs in CI, catches known vulnerabilities and misconfig before deploy. Blind to anything happening at runtime.

Runtime detection watches kernel events on live workloads and flags abnormal behavior: a container spawning a shell, reading /etc/shadow, opening an unexpected connection. This is what catches a zero-day nothing in a database has heard of yet. It can't stop a bad image from shipping in the first place.

Posture and compliance checks your cluster config against a framework like CIS Benchmarks or SOC 2. It answers the auditor's question, not the attacker's.

Most teams need exactly one tool per job. A platform selling you "all three in one" is usually a budget conversation dressed up as a coverage conversation.

Scanning before it ships

Trivy scanning CVEs, IaC misconfigurations and secrets across images, filesystems and Kubernetes clusters

Trivy is the default pick for most teams, and for good reason: one Go binary (v0.74.0 as of mid-August 2026) covers container images, filesystems, git repos, Kubernetes manifests and IaC, handling CVEs, secrets, misconfig and SBOM generation in one pass. It reads straight from a registry, so no Docker daemon required.

The misconfig scanner is underrated. Pointing trivy config at a deliberately sloppy Dockerfile turned up 4 failures out of 27 checks, including a CRITICAL for a token passed through an ENV line and a flag on USER root. Neither of those is a CVE. Both are exactly how containers get popped in practice. What Trivy won't do is prioritize for you: 200 findings get treated the same whether they're on an internet-facing API or a monthly batch job. That triage is on you.

Grype takes the SBOM-first route: pair it with Syft, generate a bill of materials once, then scan that artifact repeatedly instead of re-reading the image each time. It's narrower than Trivy on purpose, doing vulnerability matching well and staying out of IaC and secrets entirely.

If your org already pays for Docker, Docker Scout is one command away, but repo limits bite fast: one Scout-enabled repo on Personal, two on Pro at $11/user/month, unlimited only from Team at $16/user/month. Fine for a single flagship image, expensive for a microservice fleet. Snyk Container leans the other direction, leading with base-image remediation advice rather than a flat CVE list, though it's usually sold bundled with Snyk Open Source rather than standalone.

What scanning can't see

Falco, a CNCF graduated runtime security tool using eBPF to detect abnormal container behavior

Falco is a CNCF graduated project (the foundation's top maturity tier) using eBPF to watch kernel events in real time. A container that suddenly execs a shell or mounts something it shouldn't triggers an alert immediately, no CVE database required. The catch: it's detection-only, and the default ruleset is noisy enough against real production workloads that an unattended alert stream is worse than useless. Budget actual time for tuning.

Tetragon, a Cilium sub-project, goes a step further: because policy runs in-kernel via eBPF, it can enforce, not just observe, killing a process outright rather than just logging it. That enforcement is also the risk. Most teams run it in observation mode first before trusting it to kill anything in prod.

Compliance and the paid tier

Kubescape, an open-source Kubernetes security platform covering configuration scanning, compliance and runtime threat detection

Kubescape (CNCF incubating, v4.0.12) scans clusters, manifests and Helm charts against CIS Benchmarks, NSA-CISA guidance, MITRE ATT&CK and SOC 2, producing the actual artifact an auditor will accept. It also checks network policies and seccomp profiles, which nobody enjoys doing by hand.

On the commercial side, Wiz (now part of Google Cloud) sells correlation: tying a container CVE to cloud IAM exposure and network reachability so you know which of your 200 findings is actually exploitable from the internet. That's genuinely something open-source scanners don't do. Sysdig and Aqua Security play similar territory, both quote-only, both clearly built for a buyer with a procurement department. None of it is detection Trivy and Falco can't already do; what you're buying is prioritization and a support contract. The original post breaks down where each paid platform actually earns its price versus where it's just consolidation.

Wiring it into CI

The highest-value hour here is simple: fail builds on new HIGH/CRITICAL findings with an available fix, ignore everything else until you have a real triage process.

# scan locally first, no daemon needed
trivy image --severity HIGH,CRITICAL --scanners vuln node:18-alpine
trivy config .
Enter fullscreen mode Exit fullscreen mode

In GitHub Actions, ignore-unfixed: true matters more than any other flag, since failing a build on a CVE with no patch just trains developers to ignore the scanner entirely:

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@v0.36.0
  with:
    image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}'
    exit-code: '1'
    ignore-unfixed: true
    severity: 'CRITICAL,HIGH'
Enter fullscreen mode Exit fullscreen mode

Pin and update your base image regularly. The 17-versus-zero gap above came entirely from a base image swap, not a code change, and it's the single highest-leverage fix on this whole list.

If you're auditing what's actually in a Dockerfile, DevToolLab's dockerignore generator is worth a minute to make sure .env and .git never reach the build context a scanner has to find in the first place.

Picking a stack

Solo dev or side project: Trivy in CI, nothing else. Fail on fixable HIGH/CRITICAL, bump the base image monthly. Costs nothing.

Small team on Kubernetes: Trivy in CI plus Kubescape on a weekly cron against the cluster. Add Falco in observation mode once someone's actually committed to reading the alerts.

Regulated environment: Kubescape for SOC 2/CIS evidence, Trivy for scanning, Tetragon where a control specifically demands prevention over detection. Fully open source, fully auditable, and the cost shows up as configuration time instead of a license line.

Large multi-cloud fleet with a security team: This is genuinely where Wiz, Sysdig or Aqua pay for themselves. At thousands of findings across several clouds, knowing which twelve are actually reachable is the product.

References

Top comments (0)