Resolve a toxic combination
A toxic combination is a chain of edges in your cloud graph. Closing any one edge breaks the chain and resolves the combination automatically on the next scan.
Step 1, open the chain
From the dashboard or the Toxic Combinations module, click the chain you want to work on. The detail panel opens with the Attack Path tab active.
The graph shows nodes (resources) and edges (relationships). The first node is usually Internet or External; the last node is the high-value asset (a database, a bucket with PII, an admin role).
Step 2, read the chain top to bottom
Make sure you understand the path before fixing anything. Common chain shapes:
| Shape | Reading |
|---|---|
| Internet, VM, Secret, Database | A public VM holds a leaked DB credential. |
| Internet, Function, Bucket | A public Lambda has bucket-write access. |
| User (cloud A), User (cloud B), Admin role | A shared identity bridges two clouds. |
| Internet, VM, Role, Database | A public VM assumes a role with DB write. |
Click each node to confirm what it is. Click each edge to read the underlying finding(s).
Step 3, pick the cheapest break-point
The detail panel suggests a break-point (highlighted in the graph). The suggestion prefers fixes that:
- Affect the smallest blast radius (don't break unrelated things).
- Are reversible (configuration change, not data deletion).
- Match your team's standard practice (rotate keys vs change IAM policy, etc.).
You can pick a different edge. Common choices:
| Chain leg | Cheapest fix |
|---|---|
| Internet, VM | Restrict the security group, attach a private IP, put behind LB. |
| VM, Secret | Rotate the secret, remove from disk, use IAM role instead. |
| Identity, Role | Drop wildcards, use SCPs / Conditions. |
| Database, External | Revoke the cross-account share or scope it to specific resources. |
| Function, Bucket | Replace bucket-write with bucket-read, or split the function. |
Step 4, apply the fix
Click the finding you decided to close. The Remediation tab shows tabs:
- Console: click-by-click steps in the cloud console.
- Terraform: an HCL diff to merge into your IaC repo.
- CLI: a script using the cloud's CLI tool.
Pick the path that matches your team's workflow.
If you have IaC, prefer the Terraform fix. The IaC scanner will detect the fix on the
next push and the finding's drift_status will move to code_only then (none) once
deployed.
Step 5, wait for the next scan
Once the fix is applied in the cloud, you don't have to mark anything in Ctadel.
The next scan re-evaluates the chain. If the edge is truly closed, the underlying
finding moves to RESOLVED and the toxic combination disappears from the list.
Step 6, verify
After the next scan:
- The toxic combination should be gone from the Toxic Combinations page.
- The dashboard's chain count should decrement.
- The underlying finding stays
RESOLVEDif it really is fixed; otherwise it auto re-opens with a flag.
If the toxic combination is still OPEN after one scan cycle, your fix did not break the chain. Either:
- The fix didn't take (verify in the cloud console).
- The chain has redundant paths (close another edge too).
- The pattern matched a different finding than the one you closed.
Common pitfalls
- Premature claims of fix. Apply the fix first, then verify on the next scan. The status is set automatically, you do not mark it.
- Closing the wrong edge. A chain like
Internet → ALB → Servicecannot be closed by just removing the public IP, because the ALB is intentionally public. Look further along the chain. - Whack-a-mole. If the same chain reappears after you close it, the cause is probably in your IaC. Fix at the source.
What's next
- Toxic combinations concept
- Triage open findings, the broader workflow
- Suppress or ignore a finding, when the chain is intentional