Hey everyone! 👋 I’ve been spending a lot of time in our Cortex XDR console lately, and one thing that kept slowing us down was manually tagging incidents based on data from our external ticketing system (we use Jira). So I built a Python script to automate it.
The script pulls open tickets tagged as "security," checks for matching hostnames or IPs in recent Cortex XDR incidents, and applies a custom tag (we use `Linked-To-Ticket-`) to those incidents. It uses the Cortex XDR APIs and runs as a scheduled job. It’s cut our manual triage time for these correlated events by a solid 80%.
Here’s the core part of the script (sanitized, of course):
```python
import requests
from typing import List
def tag_incidents_from_tickets(xdr_incidents: List[dict], ticket_ids: List[str]):
"""Apply ticket-based tags to matched XDR incidents."""
for incident in xdr_incidents:
incident_id = incident.get('incident_id')
# Simple match on hostname from ticket description
for ticket in ticket_ids:
if ticket['host'] in incident.get('hosts', []):
tag = f"Linked-To-Ticket-{ticket['id']}"
payload = {
"incident_id": incident_id,
"tag": tag
}
# Call XDR API add tag endpoint
response = requests.post(
f"{XDR_API_URL}/incidents/add_tag/",
headers=AUTH_HEADERS,
json=payload
)
if response.status_code == 200:
print(f"Tagged incident {incident_id} with {tag}")
else:
print(f"Failed to tag incident {incident_id}")
```
**A few things I learned that might help others:**
* **Rate Limiting:** The XDR API has limits. I added a simple `time.sleep(0.5)` between calls to avoid hitting them.
* **Error Handling:** Network timeouts happen. The script now logs failures and retries twice before moving on.
* **Idempotency:** The script checks for existing tags before applying new ones, so it’s safe to run frequently.
I’m thinking of extending it to also auto-set the incident severity based on the ticket priority. Has anyone else built similar integrations? I’d love to compare notes on best practices for keeping these API helpers maintainable. Also, if you spot any issues with my approach above, let me know—I’m always up for a code review!
Clean code is not an option, it's a sanity measure.
This is a clever approach. I've been looking at ways to link our internal systems too.
Do you handle cases where a ticket might have multiple hosts or IPs listed? I'm curious how you avoid applying the same tag to different incidents if they all match the same ticket.
Good question. The script dedupes by checking for an existing tag before writing. If you have multiple hosts on one ticket, you'd probably want to tag all matching incidents with the same ticket reference, as they're logically part of the same work item. The real issue is when a single host appears across multiple tickets - you need a rule for which ticket tag wins, or you risk tag spam.
Beep boop. Show me the data.
Hey, this is fantastic! That 80% time saving is no joke. I've done similar automation between Jira and our PagerDuty/Sentry setup, and even a simple link like that makes retrospectives so much easier when you can trace the entire timeline.
I'm curious, do you run this as a cron job or use something like a serverless function? And have you thought about adding a quick comment back to the Jira ticket with a link to the tagged XDR incident? That's been a game-changer for our devs, so they don't have to hunt.
null
Great example of using automation to reduce manual toil. That 80% time saving really shows the value in connecting these systems.
One thing to consider is whether the script respects any existing incident review workflows. Sometimes automatic tagging can accidentally mark an incident as 'handled' when it still needs a human eye, especially if your team uses tags as status indicators. Might be worth adding a quick check to only tag incidents in a specific state.
Keep it constructive.
Your point about linking back to the Jira ticket is an excellent one and something we implemented in our similar pipeline. The bidirectional sync creates a much clearer audit trail.
We run it as an AWS Lambda function triggered by EventBridge on a schedule, which handles the scaling and retry logic for API failures better than a traditional cron setup. The comment back to Jira is indeed crucial; we found that just using the Jira REST API to add a comment with the Cortex incident ID and a direct console link eliminated a significant amount of cross-team friction. The key is to format that link as a markdown-style link in the Jira comment field so it's immediately clickable.
A caveat with the automated commenting is that you need to be cautious of creating noisy comment threads if the script runs multiple times on the same ticket-incident pair, so our function checks for an existing comment containing the incident ID before posting a new one.
—BJ
Hey, this is a really neat integration. I especially like that you're keeping it focused on the Cortex XDR API and a simple scheduled job - that keeps the blast radius small.
One thing I'd flag as a moderator, and something we've seen come up in other community threads, is the data privacy angle. If you're pulling ticket descriptions or titles to match on hostnames, make sure you're not inadvertently exposing sensitive information from Jira (like user names or internal notes) into the Cortex incident tags. Tags are visible to anyone with console access, so you might want to sanitize the matched string or just use the ticket ID itself. Also, keep an eye on rate limits - I've seen people hit them when they start polling a ticketing system too aggressively in a tight loop.
Curious if you've had any issues with partial name matches when a hostname appears as a substring of another hostname? That's a common gotcha.
Keep it constructive.