Hey everyone! 👋 I've been deep in the weeds with Prisma Cloud for a few months now, and one of the most impactful (but initially tricky) automations I've set up is getting critical cloud vulnerabilities to automatically create Jira tickets for my team. It saves us from constantly monitoring the dashboard and ensures nothing slips through. I wanted to share my step-by-step process, the pitfalls I hit, and the config snippets that finally made it work.
First, you need to navigate to **Automation > Notifications** in Prisma Cloud. The built-in Jira integration is fairly robust, but it requires careful mapping. Here's the key: you don't want *every* alert creating noise. We filter for critical vulnerabilities (`severity = 'critical'`) and specific resource tags (like `env:production`). The real magic happens in the custom JSON payload.
Here’s the notification JSON we crafted. This formats the Jira ticket with all the details our security engineers need right up front:
```json
{
"fields": {
"project": {
"key": "SEC"
},
"summary": "Prisma Cloud Critical Vulnerability: {{alert_title}} on {{resource_name}}",
"description": "**Resource ID:** {{resource_id}}nn**Cloud Account:** {{cloud_account}}nn**Vulnerability Details:**n{{alert_description}}nn**Recommended Action:**n{{alert_recommendation}}nnPrisma Cloud Link: {{alert_url}}",
"issuetype": {
"name": "Bug"
},
"priority": {
"name": "Highest"
},
"labels": ["prisma-cloud", "vulnerability", "{{cloud_type}}"]
}
}
```
**The gotchas I encountered:**
* **Rate Limiting:** Our initial setup triggered on *all* high-severity findings. We were quickly throttled by Jira's API. The severity + tag filter is a must.
* **Field Mapping:** The Jira field names (like `priority.name`) are case-sensitive and must match your project's schema exactly. We spent a day debugging why 'Highest' priority wasn't setting until we realized our instance used 'Critical'.
* **Dynamic Labels:** Using the `{{cloud_type}}` variable in labels (as shown) is great for filtering in Jira, but ensure the label doesn't have spaces or special characters.
* **Deduplication:** Prisma can re-report the same vulnerability on the same asset. We added a custom rule in our Jira automation to check for existing open tickets with the same `{{resource_id}}` and vulnerability ID (pulled from `{{alert_rule_id}}`) to avoid spam.
After the tickets are created, we have a separate Jira automation rule that assigns them based on the `cloud_account` field (e.g., AWS-Prod tickets go to the cloud team, Azure-Dev to the app team). This workflow has cut our mean time to respond (MTTR) for critical issues down from days to a few hours.
I'm curious if anyone else has set up similar pipelines, especially if you've integrated it with Slack for acknowledgments or ServiceNow for a full ITSM workflow. What other filters are you using? Have you found a way to auto-close tickets when Prisma marks an issue as resolved? Let's compare notes!
—B
Backup first.