Hi everyone. I'm relatively new to the data engineering side of things and I've been tasked with helping to manage our cloud security alerting pipeline, which uses Wiz. We have it set up to automatically create Jira tickets for high-severity findings so our security and dev teams can track remediation.
The problem is that we're seeing a huge number of duplicate tickets. For example, a single finding about an overly permissive storage bucket might spawn 3 or 4 identical Jira issues within minutes. It's creating a lot of noise and the teams are starting to ignore the queue, which is obviously bad.
Our integration is pretty much out-of-the-box. We're using the Wiz webhook to push to a small Python service that then uses the Jira API to create the ticket. I'm nervous about making changes here because I don't want to break the flow and miss a critical alert.
Here's a simplified version of our listener logic (the real one has more error handling):
```python
@app.route('/wiz-webhook', methods=['POST'])
def handle_wiz_alert():
data = request.json
issue_key = data['cloud_metadata']['resource_id']
# Check if a ticket for this resource+finding already exists
jql_query = f'project = SEC AND labels = wiz_{issue_key}'
existing = jira_client.search_issues(jql_query)
if len(existing) == 0:
# Create new ticket
issue_dict = {
'project': {'key': 'SEC'},
'summary': data['finding']['title'],
'description': data['finding']['description'],
'labels': [f"wiz_{issue_key}"]
}
new_issue = jira_client.create_issue(fields=issue_dict)
```
From what I can tell, the webhook might be firing multiple times for the same event. Should we be deduplicating on the Wiz side before the webhook is sent, or is our service's deduplication logic flawed? Maybe we're using the wrong unique identifier (`resource_id` doesn't seem to be enough if it's a finding that can reappear).
Has anyone else run into this? What's a safe, reliable pattern to ensure one Jira ticket per unique *finding instance*, without dropping real new alerts?
That JQL query check is your first problem. You're likely checking for an existing ticket *before* creating the new one, but you have no locking mechanism on the webhook endpoint itself. If Wiz sends two webhook calls for the same finding within a second, you'll have two requests pass that check and create two tickets.
Your Python service needs to handle concurrent duplicate detection. Add a simple in-memory cache (like a dict) of recently processed `resource_id` + finding type combinations with a short TTL, and reject duplicates instantly. Or, if you must query Jira, use a mutex or a distributed lock if your service scales.
-- bb
That in-memory cache is a band-aid that'll fall off the second you scale to two pods. Wiz webhooks can be weirdly bursty too, a TTL might not save you.
Better to make the ticket creation itself idempotent. Use the Wiz finding ID as part of the Jira ticket key or stash it in a custom field. Then your "check before create" JQL can actually be reliable because the finding ID is the source of truth, not a timestamp race.
Or just let it create dupes and have a downstream cleanup job. Sometimes it's easier to embrace the chaos and fix it later.