Toxic combinations & attack paths
The mental model
An attack path is a chain of edges in the cloud graph that, taken together, lead an attacker from outside your environment to a high-value asset.
Internet → Public VM → Leaked DB credentials → Database with PII
Each edge is, on its own, a finding (or a configuration). Attack paths are the multiplications: two MEDIUM findings joined by an edge can be CRITICAL together.
Why this is the right primitive
Listing findings flat doesn't tell you what to fix first. Most environments have a few hundred OPEN findings; a security engineer can't fix all of them in a sprint. Toxic combinations re-rank the list by what actually breaks paths:
- Closing a public bucket that's not on any path? Useful, but no incident is one step away.
- Closing a public VM that holds a leaked secret leading to PII? That's the fix that closes a critical incident vector.
In real environments, the top 10 toxic combinations cover the top 80% of risk. Fix those and your security posture jumps measurably.
Worked example
The demo runs a toxic combination called "Public VM with critical CVE leaks DB credentials to a PII database". The chain:
- Internet can reach
prod-api-7f3b9a(public VM). - The VM has a
CRITICALCVE (CVE-2021-44228Log4Shell). - On the VM's filesystem, a config file contains a valid
DATABASE_URL(secret finding). - That URL grants access to RDS instance
prod-orders. prod-ordersholds rows matching PII patterns (DSPM finding).
Five findings, four detectors, one incident. The toxic combination finding has:
- Severity
CRITICAL, score 97/100. - The full path as a graph (clickable).
- The list of resources to remediate.
- A list of break-points ("close any one edge to break the chain").
What rules ship at launch
The toxic-combination rule set spans these categories:
| Category | Examples |
|---|---|
| Exposure | Internet → public VM → DB; Internet → bucket with PII |
| Privilege escalation | Pod → cluster-admin role; user assumes prod-deploy role |
| Data leak chains | Lambda → bucket with PII; DB shared with external account |
| Identity | Same email admin in AWS + GCP; service account chain |
| Configuration | Two VMs sharing a key, one stopped/abandoned |
| Multi-cloud chains | Cross-account share + external admin |
graph.
Status workflow
Toxic combinations have the same status as findings: OPEN, IGNORED, RESOLVED. They
recompute on every scan: if any edge of the chain breaks, the combination drops back to
RESOLVED automatically. You don't have to mark it resolved manually.
If you IGNORE a toxic combination because the path is intentional (rare), record the
reason in the audit log, it's the kind of thing auditors will ask about.
What's next
- The Toxic Combinations module, the UI deep dive
- The security graph, what the rules query against
- Resolve a toxic combination, runbook