Kubernetes security tools, by what they actually do

"Top 10 Kubernetes security tools" lists put Falco next to Trivy next to Kyverno as if you would pick one. You would not. They do different jobs, and a cluster that runs all three is not being greedy.

Kubernetes security splits into seven layers, each asking a different question. The table below answers them: which layer, which open-source tools, which paid ones. The sections after it take each row in turn, with what changed in 2025–2026, and the post ends with a free starter stack. StackRadar, our product, sits in exactly one of the seven layers, and the post says which.

The seven layers at a glance

1. Posture and configuration

The question this layer answers: is the cluster set up the way the hardening guides say it should be?

The CIS Kubernetes Benchmark, the NSA/CISA hardening guidance and the Pod Security Standards define the checks; these tools run them.

• kube-bench (Aqua) runs the CIS Benchmark against control-plane and worker nodes.
• Kubescape (ARMO, CNCF incubating) scans manifests and live clusters against several frameworks and maps RBAC. It is the most complete free posture tool, and it also does vulnerabilities and runtime detection.
• Polaris (Fairwinds) and Checkov (Palo Alto) check manifests for best-practice violations; Checkov covers Terraform and other IaC too.
• Trivy scans manifests and Helm charts for misconfiguration alongside its vulnerability scanning.

Posture findings are mostly static: fix the manifest, re-run the scan, done. That is why free tools cover this layer well, and why a paid platform adds little here beyond a dashboard across clusters.

2. Vulnerability scanning

The question this layer answers: which known CVEs are in the images we are actually running, and which of them matter?

This layer changes every day without anyone touching the cluster: new advisories land against images that were clean when they were deployed. That makes it the layer with the largest ongoing workload.

• Trivy Operator scans running workloads and stores the results as CRDs in the cluster.
• Kubescape does the same, with a relevancy filter that marks which vulnerable packages are actually loaded.
• Grype and Syft are the building blocks for a do-it-yourself pipeline: Syft writes the SBOM, Grype matches it.
• The StackRadar CLI scans what a cluster is running from your laptop, flags KEV entries, and can fail a CI run on them with stackradar scan --fail-on kev. No account needed.

StackRadar is this layer and nothing else. An open-source in-cluster scanner keeps a CycloneDX SBOM for every running image. The SaaS re-matches those SBOMs as advisories land, shows every cluster in one place with history, and ranks each finding by likelihood × consequence, using EPSS and the KEV catalogue for likelihood. It does not do posture, admission, runtime, network, secrets or supply chain.

This layer has its own posts: the open-source scanners for Kubernetes, scanning tools sorted by job (CI, registry, cluster), and StackRadar vs Trivy Operator. The comparison pages cover the paid alternatives.

3. Admission policy

The question this layer answers: should this object be allowed into the cluster at all?

• Pod Security Admission is built in and enforces the Pod Security Standards per namespace. Turn it on first.
• ValidatingAdmissionPolicy (GA in 1.30) and MutatingAdmissionPolicy (GA in 1.36) express rules in CEL inside the API server, with no webhook to run. They cover simple validate and mutate rules.
• Kyverno writes policies as Kubernetes resources and can validate, mutate, generate resources and verify image signatures. It is the most approachable of the engines and became a CNCF graduated project in March 2026. Nirmata, which created it, sells the commercial version.
• OPA Gatekeeper uses Rego and fits where policy is shared with non-Kubernetes systems. OPA's core maintainers moved from Styra to Apple in August 2025 and Styra's commercial products were handed to the community; OPA itself stays a CNCF graduated project.

Admission is also where vulnerability scanning meets enforcement: "reject images with a critical CVE". That policy is only as good as the scan behind it, and on day one it tends to block a system image nobody can patch quickly. Run it in audit mode first and look at what it would have rejected.

4. Runtime detection

The question this layer answers: is something happening in a running container that should not be?

• Falco (CNCF graduated) matches syscalls and Kubernetes audit events against rules: a shell spawned in a container, a write under /etc, an outbound connection from a pod that never makes one.
• Tetragon (part of the Cilium project) observes the same kind of events with eBPF and can enforce, killing a process in the kernel instead of only alerting.
• KubeArmor (CNCF sandbox) is enforcement-first: it applies allow-list policies through Linux Security Modules (AppArmor, BPF-LSM, SELinux).

The commercial platforms add managed rules, forensics and response: Sysdig Secure (Sysdig created Falco), Aqua, Defender for Containers, Wiz's runtime sensor and Cisco's Isovalent runtime security, built on Tetragon. Runtime has the highest running cost of the seven layers: rules need tuning, and alerts need someone awake to answer them.

5. Network

The question this layer answers: which pods are allowed to talk to which, and to the outside?

NetworkPolicy is the API; your CNI enforces it, or does not. Some CNIs, such as Flannel on its own, accept NetworkPolicy objects and silently ignore them. Cilium and Calico enforce the standard API and extend it with L7 rules, DNS-based egress and cluster-wide policies.

A default-deny policy per namespace, egress included, is the highest-value change in this layer, and it needs no new tool.

6. Secrets

The question this layer answers: where do credentials live, and who and what can read them?

Kubernetes Secrets are base64-encoded, not encrypted. Check that encryption at rest is on before adding anything else.

• External Secrets Operator syncs secrets from a cloud secret manager or Vault into the cluster. It paused releases in August 2025 for lack of maintainers and resumed that September with a larger team.
• Sealed Secrets and SOPS let you commit encrypted secrets to Git.
• HashiCorp Vault, now owned by IBM, has been under the Business Source License since 2023. OpenBao is the open-source fork, under the Linux Foundation. The cloud secret managers are the other common source of truth.

The part most often left wide open is RBAC: check who can get or list Secrets in each namespace.

7. Supply chain

The question this layer answers: was this image built from the source it claims, by the pipeline it claims, and has it been altered?

• Sigstore cosign signs images and attaches attestations, such as SBOMs and SLSA provenance, to them in the registry.
• Kyverno (verifyImages) and Ratify (CNCF sandbox) check those signatures at admission.
• Chainguard sells minimal, signed base images with an SBOM per build. Docker Hardened Images, a similar catalogue, became free under Apache 2.0 in December 2025.

Security tools are part of your supply chain too. In March 2026 attackers used stolen credentials to publish a malicious Trivy release and re-point most of the trivy-action tags at a credential stealer (advisory). Pinning the action to a commit SHA protected most pipelines. The exception was older commits that fetched a helper action by tag, which the attacker had rewritten too. Pin CI actions to commit SHAs and images to digests, whichever scanner you run, and check what your pinned actions pull in.

This layer produces the SBOM at build time; the vulnerability layer uses it afterwards. The two meet in the cluster-level SBOM: what was signed and shipped versus what is actually running. For the build-time side, see SBOM tools compared and CycloneDX vs SPDX.

Where the CNAPPs fit

Wiz (part of Google since March 2026), Orca, Cortex Cloud (formerly Prisma Cloud), Sysdig, Aqua and Defender for Cloud each cover most of the seven layers across clouds in one product, plus identity and cloud posture that have nothing to do with Kubernetes. That consolidation is the product.

It is the right buy for a security organisation that would otherwise run nine tools with nine dashboards. It is an expensive way for a platform team to get the two layers it actually needed. Most are quote-only; Wiz's AWS Marketplace listing, one of the few public prices, starts around $24,000 a year per 100 workloads.

Whichever scanner you pick, rank by exploitation

Every tool in the vulnerability layer produces a long list, and CVSS alone sorts it badly. Two free feeds shorten it: the CISA KEV catalogue (evidence that a CVE is being exploited) and EPSS (the probability that it will be). Grype now uses both by default; Trivy and Trivy Operator do not, so you join them yourself or use a platform that does.

Frequently asked questions