Hey everyone! I've been deep in Wiz for about six months now, and while the platform is fantastic for visibility, I kept hitting a snag with alert fatigue. My team was drowning in a single, noisy Slack channel for *all* findings. Critical cloud misconfigurations were getting lost next to minor container vulnerabilities.
So, I built a little automation using Wiz's API to route findings directly to the responsible team's channel. It's been a game-changer for response times. Here's the basic workflow:
1. **Trigger:** A new High or Critical finding is created in Wiz (using the `Issues` API or a webhook).
2. **Enrich:** My script (a simple Python service) fetches the finding details and identifies the "Owner" (e.g., Cloud Infra, App Team A).
3. **Map & Route:** I maintain a simple mapping table (team owner -> Slack channel ID). The script posts a formatted alert to the right channel.
The magic is in the enrichment. I use the `project` and `resourceGroup` tags from the finding to determine ownership. Our tagging strategy was already decent, but this forced us to clean it up—a nice side benefit!
Key pieces you'll need:
* A Wiz API token with appropriate permissions (we use a service account).
* Your Slack app's Bot Token and the channel IDs.
* A simple serverless function (we use AWS Lambda) or a small internal service to handle the logic.
The payload to Slack includes the finding title, severity, Wiz direct link, and the most crucial details like resource ID. It looks something like this in our channels:
🚨 **New Critical Finding: Publicly Accessible Storage Bucket**
* **Resource:** `arn:aws:s3:::our-example-bucket-2024`
* **Project:** `payment-microservice`
* **Team:** `@platform-eng`
* [View in Wiz]( https://app.wiz.io/...)
This has cut our mean-time-to-acknowledge by over 70% because alerts aren't getting buried. Has anyone else built something similar? I'd love to compare notes on how you're handling the ownership mapping—tags can get messy!
Cheers!
Cleaning up your tagging strategy was the real win here, not the script. That's a one time benefit. What's the ongoing cost? You're now running a custom service that sits between Wiz and Slack. Who maintains it when the API changes? Who's on call for it? You've just added a single point of failure and a hidden support burden.
Show me the data
You're right about the maintenance cost, that's a valid concern. In our case, we packaged the script as a container and deployed it as a scheduled Cloud Function - it's stateless and costs pennies a month. API changes are a real risk, but Wiz's webhook payloads have been stable for us.
The hidden support burden is the real catch. We solved it by making the team-channel mapping a config file in git, so teams can update their own routing without touching the service. It shifts the ownership back to them.
If this becomes a burden, we'd probably move to a managed tool like Zapier. But for now, the reduced alert fatigue is worth the lightweight infra.
Pipeline Pilot