Most engineers think…
Most people treat Kubernetes security as 'put a network policy in and call it done'. That view misses two-thirds of the attack surface.
Wiz covers Kubernetes across three time horizons: before the workload runs (KSPM finds misconfigurations in cluster config, RBAC, and network policies agentlessly), while it runs (an eBPF-based runtime sensor watches system calls and blocks live threats in containers and serverless), and before the image is even built (Wiz Code integrates into CI/CD to gate on vulnerable images and misconfigured IaC). All findings flow into the Wiz Security Graph so you see which misconfig + exposed CVE + internet-facing pod combination actually creates a reachable attack path — and fix that, not every low-severity finding.
① Why Kubernetes security needs three layers, not one
Kubernetes is the most popular way to run containerised workloads in the cloud, and it is one of the most misconfigured. A single cluster typically has control-plane settings (API server flags, etcd access, audit logging), workload settings (privileged pods, hostNetwork, hostPID, excessive RBAC, missing resource limits), and a supply chain (container images from public or private registries that may carry unpatched CVEs). Each layer can be exploited independently — and attackers routinely chain all three.
The conventional response is three separate tools: a CSPM for posture, an agent-based EDR for runtime, and a scanner bolted onto CI. The problem is that findings are siloed — a critical CVE in an image that is never actually deployed looks just as loud as one running in an internet-facing pod with a privileged container. Wiz addresses this by connecting all three layers into one Security Graph, so the highest-risk chain (misconfigured + vulnerable + exposed) rises to the top automatically.
KSPM, runtime, and shift-left are not optional extras — they are three mandatory sight-lines on the same cluster.
What is the main advantage of connecting KSPM, runtime and image scanning into one Security Graph?
② KSPM & admission control — catching misconfig before it runs
Wiz's KSPM (Kubernetes Security Posture Management) works agentlessly: it reads the Kubernetes API server, inspects cluster configuration, workload specs, RBAC bindings, network policies and audit logs — with no sidecar, no DaemonSet, and no API server plug-in required. It flags pods running with privileged: true, hostPID: true, or hostNetwork: true, RBAC roles with wildcard permissions, missing Pod Security Standards, unencrypted etcd, and publicly exposed dashboards, all mapped to CIS Kubernetes Benchmark controls.
Admission controller gating
For teams that want to block non-compliant workloads at deploy time, Wiz integrates with admission controllers such as OPA/Gatekeeper and Kyverno by surfacing the same policy rules that KSPM checks. A pod spec that would create a KSPM finding can be rejected by the admission webhook before it ever lands in the cluster, closing the loop between posture visibility and active enforcement.
Reads the Kubernetes API agentlessly — no sidecar — and checks cluster config, workload specs, RBAC and network policies against CIS benchmarks.
A lightweight DaemonSet at the kernel level that watches system calls, process events and network connections across all pods on a node — detects and blocks live threats.
Scans images in Amazon ECR, Azure ACR, Google Artifact Registry and Docker Hub for CVEs, secrets and malware before they run in the cluster.
CLI that integrates into CI/CD pipelines — GitHub Actions, GitLab, Jenkins — to scan images and IaC, failing builds that violate security policy before the image is pushed.
KSPM finds what is already misconfigured; an admission controller prevents the next misconfiguration from landing. In an interview, name both: KSPM for continuous visibility, OPA/Gatekeeper or Kyverno (fed by Wiz policy rules) for active enforcement at deploy time. They are complementary, not alternatives.
How does Wiz KSPM scan a Kubernetes cluster without a sidecar?
③ Runtime protection & registry scanning — watching what's already running
For threats that get past posture checks — lateral movement, crypto-mining, container escapes — Wiz deploys a lightweight eBPF-based runtime sensor. Unlike a traditional sidecar, it sits at the kernel level as a DaemonSet, observing system calls, network connections, and process execution across all pods on a node. It detects anomalous behaviour (unexpected process spawns, outbound connections to C2 infrastructure, privilege escalation attempts) and can block threats in real time with no changes to workload manifests.
Registry scanning complements runtime by catching vulnerable images before they run. Wiz integrates with Amazon ECR, Azure ACR, Google Artifact Registry and Docker Hub, scanning every pushed image for OS-level CVEs, package vulnerabilities, exposed secrets, and malware signatures. Results are correlated with the cluster's running workloads in the Security Graph — so Wiz can tell you not just that an image has a critical CVE, but that it is running in a privileged pod with a public load-balancer in front of it.
This runtime-plus-registry combination means Wiz covers the gap that pure posture tools miss: a perfectly configured cluster can still be compromised if it runs a vulnerable image.
Registry scanning catches CVEs in stored images. It cannot detect a threat that executes after the image is running — a crypto-miner, a C2 beaconing process, or a container escape all need the eBPF runtime sensor. Always cover both the supply chain (registry scan) and the execution layer (runtime sensor).
▶ Watch a vulnerable image get caught before it reaches production
Step through how Wiz catches a critical CVE from CI/CD to runtime. Press Play for the healthy block path, then Break it to see the classic miss.
A privileged container in your cluster starts spawning unexpected shell processes. Which Wiz component would detect and block this at runtime?
④ Wiz Code shift-left & the Security Graph — fixing risk at the source
Wiz Code is Wiz's developer-facing shift-left module. The Wiz CLI integrates into CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, Harness) as a pipeline step that scans container images, IaC (Terraform, Helm charts, Kubernetes manifests), and source code for vulnerabilities and misconfigurations. If a build violates a defined policy — say, a critical CVE with a fix available, or a Helm chart that sets privileged: true — the pipeline fails before the image is pushed to the registry or deployed to the cluster. Developers get immediate, actionable feedback in the PR or CI log.
The Wiz Security Graph
Every finding from KSPM, runtime, image scanning, and Wiz Code flows into the Wiz Security Graph. The graph models relationships: this CVE lives in this running container, which has this RBAC binding, which can reach this S3 bucket over this network path. Instead of thousands of isolated findings, you get a small number of toxic combinations — the attack paths that, if exploited, would have real blast radius. Fix those first; everything else is noise reduction.
Priya at a Mumbai fintech faces this
A Kubernetes cluster passes an internal audit but the security team finds a crypto-mining process running inside a non-privileged container three weeks later. The container image was pulled from a public registry.
The cluster posture was clean (KSPM passed) but the image had a known vulnerability that allowed a container escape, and no runtime monitoring was in place to detect the anomalous process.
Wiz Security Graph shows the image had a critical OS CVE with a public exploit, the registry was not scanned, and no runtime sensor was deployed. KSPM alone cannot catch threats that execute inside a running container.
Wiz Dashboard ▸ Vulnerabilities ▸ Running Containers + Runtime ▸ Process EventsEnable Wiz registry scanning on the private and public image pulls, deploy the eBPF runtime sensor DaemonSet, and add Wiz Code to the CI/CD pipeline to block critical-CVE images before they are pushed. Tune the Security Graph to surface the image-CVE + running + internet-exposed combination.
Re-test: a freshly pushed image with the same CVE fails the pipeline; the registry scan raises a critical finding; the runtime sensor would have detected and blocked the crypto-mining process spawn within seconds of execution.
Never escalate a Kubernetes security finding to a P1 on the CVE severity alone. Open the Wiz Security Graph and check: is this image actually running? Is the pod internet-facing? Does its service account have a dangerous RBAC binding? The path view turns a theoretical risk into a confirmed or denied blast-radius assessment in minutes.
A CI/CD pipeline is configured with Wiz Code. A developer pushes a Helm chart that sets privileged: true and the base image has a critical CVE. What happens?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: how does the Wiz Security Graph change the way you prioritise Kubernetes security findings? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- KSPM (Kubernetes Security Posture Management)
- Continuous, agentless assessment of Kubernetes cluster configuration — API server flags, workload specs, RBAC, network policies — against CIS benchmarks, with no in-cluster agent required.
- eBPF (Extended Berkeley Packet Filter)
- A Linux kernel technology used by Wiz's runtime sensor to observe system calls, process events and network connections across all containers on a node with minimal overhead.
- Admission controller
- A Kubernetes API server webhook (OPA/Gatekeeper, Kyverno) that validates or rejects workload specs before they are persisted in etcd — used with Wiz policy rules for active enforcement.
- Wiz Code
- Wiz's shift-left module: a CLI that integrates into CI/CD pipelines to scan images, IaC and source code for CVEs and misconfigurations, failing builds that violate security policy.
- Wiz Security Graph
- Wiz's graph model connecting cloud resources, identities, network paths and findings to surface toxic combinations — the small set of chained risks with a real, exploitable attack path.
- Registry scanning
- Wiz's integration with ECR, ACR, Google Artifact Registry and Docker Hub that scans pushed images for CVEs, secrets and malware, correlated with running workload context.
- Toxic combination
- A Wiz Security Graph term for a cluster of findings — misconfiguration + vulnerability + network exposure + identity permission — that together form a reachable attack path with real blast radius.
- Shift-left
- The practice of moving security checks earlier in the software delivery lifecycle — into the IDE, PR review, or CI/CD pipeline — rather than waiting until deployment or production.
📚 Sources
- Wiz — Container and Kubernetes Security solution page. wiz.io/solutions/container-and-kubernetes-security
- Wiz Academy — Container Security Scanning: From Detection to Deployment. wiz.io/academy/container-security/container-security-scanning
- Wiz Academy — Container Image Scanning: Definition, Process, and Benefits. wiz.io/academy/container-security/container-image-scanning
- Wiz Blog — Wiz magic shifts left — Wiz Code CI/CD integration. wiz.io/blog/wiz-magic-shifts-left
- Wiz Academy — CI/CD Security Scanning: Definition and Best Practices. wiz.io/academy/application-security/ci-cd-security-scanning
- Wiz — What is CNAPP? Cloud Native Application Protection Platform. wiz.io/academy/cloud-security/what-is-a-cloud-native-application-protection-platform-cnapp
What's next?
Got the K8s security model? Next, explore Wiz's cloud vulnerability management and how the Security Graph correlates CVEs with exposed attack paths to cut noise by orders of magnitude.