Wiz CWPP — Workload Vulnerability Management & Container Scanning

① How Wiz CWPP scans workloads — agentless snapshot side-scanning

Wiz CWPP connects to your cloud provider APIs (AWS, Azure, GCP, OCI) and, for each VM or container host, creates a read-only snapshot of the volume. An ephemeral Wiz runner mounts that snapshot in an isolated environment — your production workload is never touched, never paused, never slowed down. The runner then inspects every layer of the file system: installed packages, open-source libraries, configuration files, environment variables and binary contents.

This SideScanning approach means coverage is instant and complete — every VM, every container and every serverless function that Wiz can reach through your cloud API is scanned, including ephemeral workloads that exist for only a few minutes. There is no agent drift, no version mismatch, no patch window for the scanner itself.

The scan output feeds directly into the Wiz Security Graph, where each finding is enriched with context: is this workload internet-facing? What IAM role does it run under? Does that role have access to a sensitive S3 bucket? That enrichment is what turns a raw CVE list into a ranked risk queue.

② CWPP finding types — OS, libraries, secrets, malware and host config

Wiz CWPP surfaces five categories of workload risk. OS vulnerabilities are CVEs in the base operating system packages — kernel, glibc, OpenSSL, SSH daemon — drawn from vendor advisories and the National Vulnerability Database. Library vulnerabilities are CVEs in application-layer packages: npm, pip, Maven, Go modules, Ruby gems. Wiz parses package manifests and installed binaries to detect both.

Secrets, malware and host configuration

Secrets detection searches the file system and environment variable exports for high-entropy strings matching known patterns: AWS Access Key IDs, private key headers, database connection strings and OAuth tokens. A hardcoded secret is typically higher priority than a medium CVE because it grants direct access with no exploit required. Malware detection scans binary contents against known-bad signatures and heuristics. Host configuration checks the OS and daemon settings against CIS Benchmark controls — SSH permitted root login, world-writable directories, unencrypted listening services — and flags every deviation.

③ Container image scanning — registry, running containers and CI/CD gates

Container security in Wiz CWPP spans three stages. At the registry, Wiz connects to ECR, GCR, ACR, Docker Hub and private registries, pulls each image layer by layer, and runs the full finding-type analysis: OS packages in the base layer, application libraries in upper layers, secrets embedded in COPY instructions, and known-bad binaries. Findings are tied to the image tag and digest so you always know exactly which version is affected.

For running containers, Wiz correlates the image findings with runtime context: is this container actually running? Is it internet-facing? Does its pod service account have cluster-admin rights? A critical CVE in an image that is never deployed scores differently from the same CVE in a running, internet-exposed pod.

In the CI/CD pipeline, the Wiz CLI or GitHub/GitLab integration scans images at build time and can be configured to fail the pipeline if findings exceed a defined threshold — shifting the security gate left before a vulnerable image ever reaches the registry. This three-stage approach means a vulnerability caught in the pipeline never reaches production, but one that slips through is still caught at the registry or running-container layer.

④ Risk prioritisation — the Security Graph, attack paths and fix-first logic

Raw CVE counts are useless without context. Wiz addresses this through the Wiz Security Graph: a continuously updated graph database that maps every cloud resource, identity, network path, vulnerability and secret into a single model. When a CVE is found on a workload, the graph asks: is the workload internet-facing? Does it run under an over-privileged IAM role? Is that role able to reach a sensitive data store? If yes to all three, that CVE is part of a toxic combination and rises to the top of the queue.

Wiz expresses these chains as attack paths — visual graphs showing the exact steps an attacker would follow from internet exposure through the CVE to the blast-radius target. Each attack path has a criticality score and a one-click remediation guide. The practical result: instead of patching 2,000 medium CVEs in arbitrary order, a team patches the ten that actually lead somewhere dangerous, and the rest can wait for the next maintenance window.

Practical fix-first workflow

Start with Critical attack paths that combine internet exposure + a CVE with a known public exploit + an overprivileged identity. Next, sweep hardcoded secrets — they need rotation, not a patch. Then work host-config deviations by CIS priority. Container image findings should be fixed at the source (the Dockerfile or base image) so every rebuild is clean.