Wiz Explained: How the Cloud Security Platform Works and How to Use It, from Connectors to Toxic Combinations

Wiz is the cloud security platform interviewers mention most often, partly because of its growth and partly because Google bought it for $32 billion. Its central idea is simple to explain and hard to do well: read everything about a cloud estate into one graph, then only alert when several weaknesses line up into a real path to something valuable.

What it is

Wiz is a cloud-native application protection platform (CNAPP). Since 11 March 2026 it has been part of Google Cloud, keeping its brand and its support for AWS, Azure, Google Cloud and Oracle Cloud. It sells three products on one console and one graph:

• Wiz Cloud: agentless posture and risk. This covers cloud configuration (CSPM), identities and entitlements (CIEM), workload vulnerabilities, data discovery (DSPM), Kubernetes and AI workloads (AI-SPM).
• Wiz Code: scanning of repositories, infrastructure code, container images and pipelines, so the same policies apply before deployment.
• Wiz Defend: detection and response. It grew out of the 2024 acquisition of Gem Security and became generally available in April 2025. It uses cloud audit logs, SaaS and identity logs, and the Wiz Runtime Sensor.

In March 2026 Wiz announced AI agents (Red for exploit validation, Blue for investigating detections, Green for remediation guidance), drag-and-drop Workflows, and an AI application protection product. Wiz has not stated which of these are generally available.

How it works

Cloud connections. You connect each AWS organisation, Azure tenant and Google Cloud organisation, preferably at the top level so new accounts and projects are discovered automatically. Google's partner documentation shows the Google Cloud flow: Wiz generates a script or Terraform module that creates a service account with read-only roles, and an optional Security Reviewer role lets Wiz read Security Command Center findings.

Agentless workload scanning. Wiz snapshots each workload's boot volume, reads it in the same region, inventories packages, configuration, secrets and malware, then deletes the snapshot. Results are redacted and hashed before they leave the region. If you do not want Wiz-hosted scanners to touch snapshots, a Wiz Outpost runs the scanning inside your own cloud account and sends only metadata to Wiz. Optional data scanning samples buckets and databases to classify sensitive data.

The Security Graph. Resources, identities, network paths, vulnerabilities, secrets and data findings become nodes and edges. A Control is a saved graph query with a severity, and each result is an Issue. Cloud Configuration Rules evaluate single resources against a baseline and produce Findings; custom rules are written in Rego and also run against infrastructure code. Projects scope what each team can see.

Here is the idea behind a toxic combination, reduced to a few lines of Python:

assets = {
    "web-vm": {"internet": True, "crit_vuln": True, "reads": "customer-db"},
    "batch-vm": {"internet": False, "crit_vuln": True, "reads": "customer-db"},
    "api-vm": {"internet": True, "crit_vuln": False, "reads": "logs"},
}
sensitive = {"customer-db"}

for name, a in assets.items():
    path = a["internet"] and a["crit_vuln"] and a["reads"] in sensitive
    print(f"{name:9} {'ISSUE: toxic combination' if path else 'finding only'}")
# => web-vm    ISSUE: toxic combination
# => batch-vm  finding only
# => api-vm    finding only

All three machines have something wrong, but only one has every link of an attack path. A raw vulnerability count would rank them the same.

How to use it

Day one: connect and decide where scanning runs

1. Connect at the organisation level for each cloud, with the least privileged role set Wiz offers for your chosen features.
2. Choose Wiz-hosted scanning or an Outpost. Regulated workloads often need snapshots to stay in your account.
3. Decide on data scanning with your privacy team, because it samples real data to classify it.
4. Connect source control and registries for Wiz Code, and stream audit logs if you will use Wiz Defend. On Google Cloud that means routing audit logs to Pub/Sub; check VPC Service Controls perimeters, which need an explicit ingress rule for Wiz.

Week one: structure before triage

1. Create Projects that match how your company owns things: one per business unit, product or workload account, with access mapped from your identity provider. Without Projects, every team sees everything and owns nothing.
2. Start with critical Issues, not Findings. Open each one in the graph and confirm the path: exposure, then vulnerability or misconfiguration, then the permission that reaches the data. Fix the cheapest link; removing an over-broad role often closes several Issues at once.
3. Pick a compliance framework if audits matter, and treat its score as a reporting view, not a queue.

Every day: route, gate and detect

• Route Issues to owners through automation rules or Workflows into Jira, ServiceNow or chat, with severity-based deadlines. Wiz's own product security team describes this as the core of its process.
• Shift left with the same policies: the Wiz CLI scans infrastructure code and images in CI, and the Wiz admission controller blocks non-compliant Kubernetes objects before they are created.
• Run detection with Wiz Defend and the sensor where you need runtime evidence, and write custom detections for your environment.
• Use the GraphQL API (authenticated with a service account) to export inventory or build reports, rather than screen-scraping dashboards.

Where it stops

• Agentless means periodic. Snapshot scans show what is installed at scan time, not what is running now, and cannot block anything. Runtime detection needs the sensor or log-based detection.
• The graph knows what it can read. Accounts that are not connected, clouds without a connector, and SaaS without integration are invisible. Measure coverage before you trust a clean dashboard.
• Powerful permissions. The roles that let a CNAPP read every account, and with Wiz-hosted scanning create snapshots, make it a high-value target. Review them as you would any privileged integration.
• Severity is a model. Toxic combinations depend on what Wiz knows about exposure and data sensitivity; your own context, such as compensating controls, still matters.

Wiz Research

Wiz's research team is often cited in interviews:

• ChaosDB (August 2021): cross-tenant access to Azure Cosmos DB.
• The exposed DeepSeek database (January 2025).
• IngressNightmare (March 2025): CVE-2025-1974 and related flaws, which allowed unauthenticated remote code execution through the ingress-nginx admission controller. The fixes shipped in versions 1.12.1 and 1.11.5, and ingress-nginx has since reached end of life.
• RediShell (October 2025): CVE-2025-49844, a use-after-free in Redis's Lua engine.

How it comes up in interviews

• "Wiz shows 50,000 findings across 400 accounts. What do you do first?" Projects and owners, critical Issues by attack path, fix shared root causes such as broad roles, then gates to stop new ones.
• "Agentless or agent-based?" Explain snapshots, periodic coverage, no blocking, and when you add a sensor.
• "How would you verify that the platform covers everything?" Compare the account and subscription list from your cloud organisation with what is connected, and plant a known-bad test resource.

Sources

Checked on 13 November 2026: Google Cloud press releases announcing the agreement to acquire Wiz (18 March 2025) and its completion (11 March 2026); Google Cloud architecture guide "Prioritize security risks with Wiz"; Wiz blog posts on agentless scanning (31 October 2023), Gem Security (10 April 2024), Wiz Defend general availability (2 April 2025), the anatomy of a toxic combination (24 January 2025), how Wiz product security uses Wiz (9 July 2026), Wiz Agents and AI-APP (23 March 2026), IngressNightmare and RediShell; ChaosDB disclosure site; Wiz public Helm charts repository (wiz-sec/charts); Wiz integrations page.