Most engineers think…
Most people picture cloud security as a dashboard full of individual alerts — 'this bucket is public', 'this CVE is critical', 'this IAM role is overprivileged'. Triage becomes whack-a-mole and the real threats hide in noise.
The Wiz Security Graph is a relationship model, not a flat list. It connects a public bucket to the identity that can write to it, the workload running as that identity, and the CVE on that workload — so one query surfaces the entire chain. That is the shift from siloed alerts to context-driven security, and it is what lets a small team triage what actually matters.
① What the Wiz Security Graph actually is — nodes, edges, one model
The Security Graph is Wiz's core data layer: a continuously updated directed graph in which every cloud object — a VM, a bucket, a role, a container image, a secret — is a node, and every relationship between them — 'can assume', 'is exposed to', 'runs on', 'has access to', 'contains' — is an edge. Wiz builds this graph agentlessly by scanning cloud provider APIs (AWS, Azure, GCP, OCI and others) and enriching it with runtime signals from its eBPF sensor.
The key property of a graph model is that reachability is first-class. Instead of asking 'is this resource misconfigured?' you ask 'is this misconfigured resource reachable from the internet and does it have permissions to sensitive data?' Those are relationship questions, and flat alert lists cannot answer them. The graph can, instantly, across your entire cloud estate.
What makes the Security Graph different from a flat list of cloud misconfigurations?
② The four entity classes — resources, identities, workloads, data
The Security Graph organises nodes into four main classes. Resources are cloud infrastructure objects: virtual machines, storage buckets, databases, networks, security groups, Kubernetes clusters and API gateways. Identities are anything that can authenticate and act: cloud IAM roles, service accounts, users and federated identities. Workloads are the running software layer: container images, serverless functions, OS packages and the vulnerabilities (CVEs) found on them. Data is the sensitivity layer: data stores, secrets, personally identifiable information, credentials and the classification labels Wiz assigns to them.
Why four classes?
Each class contributes a different dimension of risk. A workload class node might carry a critical CVE; an identity node might be overprivileged; a data node might hold PII. Only when you connect all four through graph edges do you know whether the CVE-carrying workload is the same one that, through its identity, can reach the PII store. That connection is what the Security Graph makes explicit.
Any cloud object: a VM, bucket, IAM role, container image, secret or data store. Nodes carry properties (CVEs, permissions, tags) and are connected by typed edges.
A directional relationship between nodes: 'can assume', 'is exposed to internet', 'has access to', 'runs on', 'contains'. Edges are what make attack paths queryable.
A co-occurring set of risk factors — e.g. internet exposure + critical CVE + admin identity + PII data — that together form a viable attack path, even if each factor alone is only medium severity.
Wiz Query Language: a declarative graph query you write (or build visually) to ask relationship questions like 'which internet-exposed workloads can reach a database tagged PII?'.
When asked about the Wiz Security Graph, enumerate the four classes — Resources, Identities, Workloads, Data — and explain that the edges between them are what enable attack-path queries. Saying 'it maps relationships across all four entity types' immediately shows graph-level understanding, not just 'it scans for misconfigs'.
Which of the four Security Graph entity classes holds CVEs and OS packages?
③ Toxic combinations & Security Graph queries — context beats alerts
A toxic combination is Wiz's term for a co-occurring set of risk factors that together form a viable attack path — even though none of the individual factors alone would be critical. The canonical example: an internet-exposed VM (resource) running as a high-privilege service account (identity) with an unpatched OS vulnerability (workload) that has network access to a database containing customer PII (data). Each factor alone gets a medium severity; together they are a P1.
You surface toxic combinations by querying the graph. Wiz provides a WQL visual explorer where you drag nodes and edges to ask questions like 'show me all internet-exposed VMs where the workload has a critical CVE AND the identity can write to any S3 bucket tagged PII'. That single query replaces days of manual correlation across three separate consoles.
The graph is also the foundation of Wiz attack path analysis. Wiz computes all viable attacker traversal paths from an internet entry point to crown-jewel data assets, ranks them by exploitability and blast radius, and surfaces them as prioritised findings — not as a flat vulnerability list.
A CVE with CVSS 9.8 on an isolated, non-internet-exposed, air-gapped VM with no identity edges to sensitive data is lower priority than a CVSS 7.2 on a public-facing VM with admin credentials to a PII database. The graph-based priority is exposure + reachability + blast radius — never raw CVSS alone.
▶ Watch a toxic combination surface and get traced in the Security Graph
Follow an attacker's potential path from internet exposure to PII data. Press Play for the healthy detection path, then Break it to see the classic failure.
A VM is internet-exposed and runs as a high-privilege service account. Each finding alone is medium severity. Why does Wiz raise a high-priority alert?
④ Graph-led triage — tracing exposure from a finding to the blast radius
When an alert fires, the graph answers the three questions every analyst needs: how did the attacker get here? (the path from internet to the resource), what can they do from here? (the outbound edges — what identities, data stores, and lateral targets are reachable), and what is the blast radius? (how many resources and data stores are reachable in N hops). Without the graph, each question requires stitching together cloud console lookups, IAM policy exports and network diagrams by hand.
Triage workflow
In Wiz, you open the finding, click 'View in graph', and the visual explorer renders the full context: the exposed node, its identity, the downstream data stores, and any active runtime signals from Wiz Defend. You can pivot from any node to see its edges. The result is a triage that takes minutes rather than hours — and a remediation recommendation that is scoped to the actual exposure, not a blanket 'patch all CVEs' directive.
Priya at a Mumbai fintech faces this
Wiz raises a high-priority toxic combination: a Kubernetes pod in the production cluster is internet-exposed, runs as a service account with overly broad IAM permissions, and has a critical CVE in its base image — and the service account has write access to an S3 bucket tagged as containing customer financial records.
The pod's service was exposed via a misconfigured LoadBalancer (no ingress whitelist), the service account inherited a legacy admin policy from a migration two years ago, and the base image was never updated after the original CVE patch was released.
Security Graph query: internet-exposed workload WITH critical CVE AND identity WITH write access to data tagged PII — Wiz surfaces this as a single toxic combination with a blast-radius view showing three more S3 buckets reachable in one hop.
Wiz Console ▸ Issues ▸ Toxic Combination ▸ View in Graph ▸ Identity edges ▸ Data nodesRestrict the LoadBalancer to internal CIDR only; replace the legacy admin policy with a least-privilege scoped IAM role; patch the container image to a fixed base. Verify each step closes the graph edge before promoting to production.
Re-run the WQL query: zero results. The Wiz issue auto-resolves within the next graph refresh cycle, and the blast-radius view shows no reachable PII buckets from that workload.
After remediating a toxic combination, verify closure by re-running the original WQL query and confirming zero results. A ticket marked 'done' in the ITSM system does not prove the graph edge is gone. Re-query the graph — Wiz will auto-resolve the issue once the relationship no longer exists.
An analyst opens a Wiz finding and clicks 'View in graph'. What does the graph view reveal that the finding summary does not?
🤖 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: why does a graph model surface toxic combinations that a flat alert list cannot? 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
- Security Graph
- Wiz's core data layer: a continuously updated directed graph of cloud objects (nodes) and their relationships (edges) across resources, identities, workloads and data.
- Node
- A cloud object in the Security Graph — a VM, bucket, IAM role, container image, secret or data store — carrying properties like CVEs, permissions and classification tags.
- Edge
- A typed directional relationship between two graph nodes, such as 'can assume', 'is exposed to internet', 'has access to', 'runs on' or 'contains'.
- Toxic combination
- A co-occurring set of risk factors connected by graph edges that together form a viable attack path, even if no single factor alone is critical.
- WQL (Wiz Query Language)
- Wiz's declarative graph query language for expressing relationship conditions across Security Graph nodes and edges — also available as a visual drag-and-drop explorer.
- Attack path
- A computed sequence of graph edges that describes how an attacker could traverse from an internet entry point to a crown-jewel data asset.
- Blast radius
- The set of resources and data stores reachable from a compromised node by following outbound graph edges — shown visually in the Wiz graph explorer.
- Agentless scanning
- Wiz's method of building the Security Graph by reading cloud provider APIs and snapshot data without deploying agents on every resource.
📚 Sources
- Wiz — Security Graph overview and CNAPP platform. wiz.io/platform/security-graph
- Wiz Academy — AI Security Graphs: contextual risk for cloud and AI systems. wiz.io/academy/ai-security/ai-security-graph
- Wiz Blog — Wiz for Microsoft 365: bringing SaaS into the Security Graph. wiz.io/blog/wiz-for-microsoft-365
- Security Scientist — 12 questions and answers about the Wiz Security Graph. securityscientist.net/blog/12-questions-and-answers-about-wiz-security-graph-wiz
- Futurum Group — At Wizdom 2025, Wiz presents a broader vision of cloud security. futurumgroup.com/insights/at-wizdom-2025-wiz-presents-a-broader-vision-of-cloud-security
- Software Analyst — Runtime security in 2025: how Wiz Defend signals the future of cloud security operations. softwareanalyst.substack.com/p/runtime-security-in-2025-how-wiz
What's next?
Got the graph? Next, go deep on Wiz CSPM policies and how to customise built-in rules, write custom controls, and tune the severity model so your team focuses on real exposure.