Wiz Cloud Security: CSPM + CWPP Review and Setup Guide
How Wiz's graph-based agentless cloud security works, what toxic combinations are, how to set up Wiz across AWS/Azure/GCP, and how it integrates with dev workflows.
Wiz Cloud Security: CSPM + CWPP Review and Setup Guide
Wiz has become the fastest-growing cloud security platform in the industry, used by a significant portion of Fortune 500 companies since its 2020 launch. Its approach — agentless scanning, a graph-based data model, and a focus on attack paths rather than individual misconfigurations — represents a meaningful departure from traditional CSPM tools. This guide covers how Wiz works technically, what makes it different, how to connect your cloud environments, and how its findings translate into actionable security improvements.
How Wiz Works: The Security Graph
Most CSPM tools check cloud configurations against a rule list and generate a flat list of findings: "S3 bucket is public," "security group allows 0.0.0.0/0," "IAM role has admin privileges." This produces hundreds or thousands of findings with no clear indication of which ones actually matter.
Wiz takes a different approach. It builds a Security Graph — a property graph database that models every resource in your cloud environment as a node, and every relationship between those resources as an edge. Nodes include EC2 instances, S3 buckets, IAM roles, Kubernetes pods, databases, network interfaces, secrets, and container images. Edges represent relationships: "this EC2 instance has this IAM role," "this role can assume this other role," "this pod runs this container image with this CVE."
The Security Graph then automatically computes attack paths — sequences of connected vulnerabilities, misconfigurations, and exposures that could be chained together by an attacker to reach a sensitive target (production database, secrets manager, admin console).
Example attack path Wiz might surface:
Internet-exposed load balancer
→ EC2 instance in public subnet with SSH open
→ Instance has overprivileged IAM role
→ Role has sts:AssumeRole on admin role
→ Admin role has access to production secrets manager
→ Secrets manager contains database credentials
None of the individual findings in this chain might be flagged as critical in isolation. Together, they represent a complete compromise path from the internet to your most sensitive data.
Toxic Combinations
Wiz's most distinctive concept is "toxic combinations" — sets of multiple security issues that, when present together on the same resource or attack path, represent a critical risk even if each issue alone would be low or medium severity.
Common toxic combinations Wiz detects:
- Exposed VM with OS vulnerability + public network access + secrets on disk — a single SSH credential could lead to secret exfiltration
- Container with critical CVE + internet exposure + overprivileged service account — exploiting the CVE gives cluster-admin access
- Publicly readable S3 bucket + bucket contains secrets or PII — data exposure through misconfiguration
- IAM role with privilege escalation path + lateral movement capability + access to production database
- Publicly accessible admin port (RDP/SSH) + unpatched OS + sensitive data on instance
Wiz's dashboard prioritizes resources affected by toxic combinations over isolated misconfigs, dramatically reducing the alert volume that security teams need to triage. Instead of 2,000 individual findings, teams typically focus on 20-50 toxic combination paths.
Agentless Architecture
Wiz requires no agents, no sensors, and no changes to running workloads. It connects to your cloud environment using read-only API access and scans disk snapshots for vulnerability data.
How agentless disk scanning works:
- Wiz uses cloud-provider snapshot APIs to create read-only snapshots of running VM and container instance volumes.
- Snapshots are mounted in Wiz's cloud infrastructure for analysis.
- Wiz scans the file system for installed packages, OS vulnerabilities, secrets, and malware indicators.
- Snapshots are deleted after analysis — no data is stored permanently.
This approach means Wiz gets OS-level vulnerability data (what's actually installed on a running VM) without deploying agents, creating firewall rules, or touching production workloads. The tradeoff is that agentless scanning is point-in-time rather than continuous — scans typically run every 24 hours.
Connecting Cloud Environments
AWS
Wiz deploys a CloudFormation stack that creates a read-only IAM role with a trust relationship to Wiz's AWS account. The role has a minimal policy covering the APIs Wiz needs:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:CreateSnapshot",
"s3:GetBucketPolicy",
"s3:GetBucketAcl",
"iam:List*",
"iam:Get*",
"rds:Describe*",
"eks:Describe*",
"lambda:List*",
"lambda:GetFunction"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateSnapshot",
"Resource": "arn:aws:ec2:*:*:volume/*"
}
]
}
For AWS Organizations, you deploy a single StackSet that creates the role in every member account simultaneously. Wiz then shows a unified view across all accounts.
Azure
Wiz uses a service principal with a custom role. Deploy via the Azure portal or CLI:
# Create app registration
az ad app create --display-name "Wiz Security Scanner"
# Create service principal
az ad sp create --id <APP_ID>
# Create custom role definition
az role definition create --role-definition '{
"Name": "Wiz Reader",
"Description": "Read-only access for Wiz security scanning",
"Actions": [
"*/read",
"Microsoft.Compute/disks/beginGetAccess/action"
],
"NotActions": [],
"AssignableScopes": ["/subscriptions/<SUBSCRIPTION_ID>"]
}'
# Assign role
az role assignment create \
--assignee <SERVICE_PRINCIPAL_ID> \
--role "Wiz Reader" \
--scope "/subscriptions/<SUBSCRIPTION_ID>"
GCP
Wiz uses a service account with custom roles:
gcloud iam service-accounts create wiz-scanner \
--description="Wiz Security Scanner" \
--display-name="Wiz Scanner"
# Grant required roles
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wiz-scanner@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/viewer"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wiz-scanner@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/compute.storageAdmin"
Kubernetes Integration
For Kubernetes clusters, Wiz uses the Kubernetes API server (no agent required) plus optional deployment of the Wiz Sensor for runtime threat detection.
Agentless Kubernetes scanning (API-based):
- Cluster configuration and RBAC analysis
- Pod security policy and admission controller checks
- Workload image vulnerability scanning via registry or snapshot
- Namespace and network policy analysis
Wiz Sensor (optional, for runtime):
# Helm installation
helm repo add wiz https://charts.wiz.io
helm install wiz-sensor wiz/wiz-sensor \
--namespace wiz-system \
--create-namespace \
--set connectorId=<CONNECTOR_ID> \
--set apiToken=<API_TOKEN>
The sensor uses eBPF for kernel-level visibility — detecting runtime threats like crypto mining, reverse shells, and container escapes with minimal overhead.
Wiz for Developers (Shift Left)
Wiz integrates into development workflows to catch issues before deployment.
GitHub Actions — scan container images before push:
- name: Wiz image scan
uses: wizcybercloud/wiz-github-actions/scan-docker-image@main
with:
image-address: "${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}"
wiz-client-id: ${{ secrets.WIZ_CLIENT_ID }}
wiz-client-secret: ${{ secrets.WIZ_CLIENT_SECRET }}
policies: "Default vulnerabilities policy,Default secrets policy"
policy-hits-to-fail: "1"
IaC scanning (Terraform, CloudFormation, ARM):
- name: Wiz IaC scan
uses: wizcybercloud/wiz-github-actions/iac-scanning@main
with:
path: "./terraform"
wiz-client-id: ${{ secrets.WIZ_CLIENT_ID }}
wiz-client-secret: ${{ secrets.WIZ_CLIENT_SECRET }}
policies: "Default IaC policy"
Policies and Alerting
Wiz policies are the rules that govern what generates issues and alerts. Built-in policy frameworks include CIS Benchmarks, NIST 800-53, SOC 2, GDPR, HIPAA, PCI DSS, and ISO 27001. Custom policies can be written in the Wiz Query Language (WQL):
// Find EC2 instances with public IP that also have secrets on disk
SELECT
i as instance,
s as secret
FROM
Instance i,
Secret s
WHERE
i.publicIpAddress != null
AND i --> s
Automation rules can trigger on issue creation, severity change, or resolution:
- Create Jira ticket on new HIGH issues
- Send Slack alert for toxic combinations in production
- Notify PagerDuty for internet-exposed databases with critical CVEs
- Auto-resolve issues when the underlying resource is remediated
Wiz vs. Alternatives
| Capability | Wiz | AWS Security Hub | Prisma Cloud |
|---|---|---|---|
| Agentless scanning | Yes | Limited | Yes (with some agents) |
| Security Graph | Yes | No | No |
| Toxic combinations | Yes | No | Limited |
| Multi-cloud | AWS, Azure, GCP, OCI | AWS only | AWS, Azure, GCP |
| Kubernetes | Yes (agentless + sensor) | Limited | Yes |
| IaC scanning | Yes | No | Yes |
| Container registry | Yes | No | Yes |
| Runtime protection | Yes (sensor) | No | Yes |
| Pricing model | Per cloud account/resource | Per finding | Per workload |
Wiz's graph model and toxic combination detection are genuinely differentiated. For organizations running multi-cloud environments with complex IAM and network topologies, the attack path visibility Wiz provides is difficult to replicate with point tools.