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?
That Salesforce comparison really clicked for me. So the investigation is like getting an instant, read-only report of everything connected to the problem, but to actually fix it you need to leave the platform.
For the response part, it sounds like the main workflow is just creating a detailed ticket in your ITSM tool. Is the expectation that your SOC team then manually acts based on that ticket, or are most teams building those custom API automations they mentioned?
Yep, you've got it. The investigation graph is the killer feature, but it's a starting point.
From what I've seen in other shops, most teams start with the SOC manually acting on the ITSM ticket. Building the custom API automations is a second-phase project, after you've tuned alerts and built trust in the data. It's a big lift.
We built a couple of those automations for clear-cut, high-severity cases like a publicly exposed S3 bucket. Even then, the Lambda that fixes it just posts the resolution back into the same Jira ticket the alert created. It's still a ticket-driven workflow, just faster.
Infrastructure as code is the only way
Spot on about the graph being the core value, but calling the response "orchestration" feels generous. It's really just a notification. The API call your automation makes isn't a bridge, it's a separate build.
I've seen two teams burn months trying to get reliable webhook Lambdas for container kills, only to revert to manual ticket actions because the latency and state issues introduced too much risk. The graph tells you what to do, but the doing is entirely on you and your brittle scripts. That's not an integrated workflow, it's a handoff to a different, more fragile system.
You've nailed the exact operational tax. We built that Lambda for killing containers exposed to 0.0.0.0/0 and the state problem is real.
The graph shows you the container *now*, but by the time your webhook fires, the pod might be recycled, the policy might be updated, or another finding for the same issue might already be processing. Our "idempotent" kill function had to check the live API state against the graph snapshot in the finding payload, which added complexity and defeated the purpose of a simple automated fix.
We kept it for S3 bucket exposures because the resource state is more persistent, but container kills went back to the ticket queue.
Automate everything. Twice.
Good questions. The Salesforce analogy others used is accurate.
> Is the investigation part more about pulling together logs from different places automatically?
No, it's not log aggregation. It's building a live dependency graph. Think of it as an automatically generated relationship report for your cloud resources. For that suspicious container, you immediately see its cluster, network rules, attached IAM role, and secrets in env vars - all in one view. It saves you from manually jumping between ten AWS/GCP consoles.
> How does the response part work?
Mostly ticketing. The native Jira/ServiceNow integration is solid and creates tickets packed with that graph context. True automated actions, like killing a container, require custom work using their API. That's a project in itself.
You'll need to build the Lambda or script to take the action, handle state changes, and make it idempotent. It's brittle. Many teams start with manual SOC response from the ticket and only automate later for clear, high-risk scenarios like an exposed S3 bucket.
—cp
Exactly. The "budget for integration work" is the hidden line item everyone underestimates. The graph context it feeds into Jira is invaluable, but the moment you want to automate a simple containment step, you're building and maintaining a separate microservice.
We found the cost wasn't just in the initial Lambda, but in the ongoing monitoring to handle those state mismatches others mentioned. It turns a seemingly simple "kill container" button into a distributed systems problem.
So it's less of a response platform and more of a superb context provider for your *actual* response systems, which you still own.
Cheers, Henry
That Salesforce report analogy really clarifies the investigation piece for me. It makes sense that the value is in building that entire relationship map automatically.
Your point about the response being a workflow kickoff, not an action platform, matches what I'm hearing. It sounds like the real project is building the "update a field" part outside Wiz, which can be a significant lift. Do you think that integration work becomes more manageable if you treat Wiz's output as a standardized data source, similar to how you'd handle any other event stream?