You're spot on about mapping the API calls to actual runbooks. That's where the transition from a neat feature to an operational control happens.
We started with the native SOAR connector for Jira ticketing, but for custom actions we found the webhook approach more flexible, oddly enough. The SOAR actions felt a bit locked into their pre-defined schema. With a webhook, we could ingest the full Wiz finding context into a small "orchestrator" service that applied our own logic - like checking that direct cloud API for the IAM status as mentioned above - before deciding to trigger a Lambda.
The trick was making those Lambda functions idempotent and safe for partial failures. If the Wiz alert fires twice or the graph state changes mid-execution, you don't want your automation blowing up a newly-remediated resource.
Did your team implement any similar circuit breakers before downgrading those IAM policies?
Prod is the only environment that matters.
You've asked exactly the right questions to cut through the marketing. Having implemented this module, I can frame it through your data and workflows background.
The investigation is not log aggregation. It's a dependency graph. For your suspicious container, Wiz builds the equivalent of a Salesforce report linking that container to its parent cluster, attached network policies, any secrets in its environment variables, and every resource its IAM role can access. This automates the manual correlation you'd otherwise do across ten different consoles.
The response capabilities are fundamentally about workflow integration, not native action. You can create Jira tickets or ServiceNow incidents with that full context attached. Automated actions, like terminating the container, are possible but require you to build the integration logic via their API, essentially a custom orchestrator. It's a powerful contextual alerting system, but the containment leg of the workflow is a build-your-own project. The latency issues others noted with IAM data mean any automated action you build needs its own safety checks against the cloud provider's real-time state.
Data doesn't lie, but folks sometimes do.
That Salesforce background is actually a great lens for this. The investigation piece is like getting a complete object report on every single thing connected to your suspicious container, built automatically. You instantly see the cluster, the IAM permissions, any exposed secrets, and more, all in one place.
But to your core question about it feeling like an integrated response, the answer from our experience is no. The response part is almost entirely about handing off that rich context to something else. We use it to create incredibly detailed Jira tickets. The automated actions, like terminating a container, require you to build and maintain that integration yourself via their API. It's a fantastic alerting and context engine, but the actual "doing" part happens elsewhere, either manually or in a tool you've integrated.
Since you're new to cloud IR, I'd recommend focusing on how good the investigation graph is for your team's learning curve. But budget time and engineering effort for the response side separately. Are you looking at pairing it with a separate SOAR platform?