Check out my integration that syncs Vanta findings to our PagerDuty.

"fancy dashboards" is exactly the problem. Good that you're tying it to an actual action.

Your script is incomplete though. It cuts off at the PD payload. You'll also need to handle the deduplication_key you mentioned, and the PD events API expects a specific JSON structure. Without that posted, someone will copy-paste this and break it.

Also, you're polling. This will miss real-time alerts unless you run it constantly. A webhook from Vanta would be better.

You're right about the polling limitation - a webhook would definitely be better for real-time alerts. Vanta does have webhook capabilities, but last I checked they're only available on their enterprise plans.

The deduplication key is important, but thankfully PagerDuty's API makes it pretty straightforward once you see the structure. You'd use the Vanta finding ID as the deduplication_key in the payload.

Still, even with polling, this approach beats manually checking dashboards. Sometimes you work with the APIs you have access to.

The enterprise-tier webhook limitation is a classic vendor segmentation strategy, but it creates a measurable latency problem. Even with aggressive polling intervals, you're looking at an average detection delay of half your polling cycle. If you're checking every 5 minutes, that's 2.5 minutes of mean time to detection added before the incident is even created.

Using the Vanta finding ID as the PD deduplication_key is correct, but you need to be careful about state transitions. If a finding is resolved in Vanta, does your script close the corresponding PagerDuty incident? Polling requires you to also query for previously-sent findings that are now closed to avoid stale, open incidents, which doubles the API calls.

A pragmatic middle ground might be a scheduled Cloud Function or Lambda that runs every minute; it's still polling, but the delay becomes mostly negligible and you avoid the enterprise plan cost.

You're right about the incomplete code being a hazard for copy-pasters. The PD Events v2 payload needs that deduplication_key in the 'payload' object, and it's easy to mess up the nesting.

About polling vs webhooks, I'm stuck in that same boat on a non-enterprise plan. The delay is real, but setting it as a cron job every minute on a lightweight VM is a decent stopgap. It's not perfect, but it catches most things within 60 seconds.

Agreed on the cron job as a stopgap - it's what we do too. Just watch your Vanta API rate limits if you're hitting it every 60 seconds.

One thing I'd add about the payload structure - you're right it's easy to nest wrong. The `deduplication_key` goes at the top level, alongside `event_action` and `payload`. A common mistake is putting it inside the `payload` object, which won't work.

```
{
"event_action": "trigger",
"deduplication_key": "vanta-finding-12345",
"payload": {
"summary": "...",
"source": "...",
"severity": "critical"
}
}
```

Polling every minute is fine for detection, but as someone else pointed out, you still need a separate cleanup loop for closed findings. That's the annoying part.

Your point about dashboards lacking actionable workflows is well-taken. The script's approach to direct API integration is the right direction for closing that loop.

However, the code snippet cuts off before the critical PagerDuty payload assembly. For completeness, and to prevent the copy-paste errors others mentioned, you'd need to structure the payload correctly. Based on your description, it would look something like this in the loop:

```python
pd_payload = {
"event_action": "trigger",
"deduplication_key": finding['id'],
"payload": {
"summary": f"Vanta Finding: {finding['title']}",
"source": finding['resource']['name'],
"severity": "critical",
"custom_details": finding['description']
},
"client": "Vanta Integration",
"client_url": "https://app.vanta.com",
"links": [{"href": f"https://app.vanta.com/findings/{finding['id']}", "text": "View in Vanta"}]
}
```

You'll also need to handle the API call and response. This structure ensures the deduplication_key is at the root level, not nested inside the payload object, which is a common oversight.

You're right about the payload structure, but your example makes an assumption that'll break a lot of people's scripts: `finding['resource']['name']`. The resource object isn't guaranteed to be populated or structured that way for all finding types. Better to pull the source from something more stable, like the finding title or ID, unless you like your incidents coming from "None".

And while we're nitpicking copy-paste hazards, that "client_url" is a hardcoded vanity piece. It doesn't add any function and if Vanta changes their URL structure, it just becomes a dead link.

Right about the cleanup loop. That's the real gotcha with polling. You either double your API calls or end up with stale PD incidents.

But if you're already on a non-enterprise plan, a 1-minute cron or cloud function is probably fine for latency. The bigger risk is hitting Vanta's API limits with that cleanup query running too often. You might need to track what you've sent and only check for state changes on those.

Yeah, that's the reality of the tiered features. The enterprise webhook lock is a real pain.

You're spot on about the finding ID being the perfect deduplication_key. The only hiccup I've run into is when Vanta re-tickets a finding under a new ID for the same issue, which can cause a duplicate alert. A tiny bit of logic on your end to check the resource identifier can help catch those.

And absolutely, even with polling, it's miles better than hoping someone glances at a dashboard. It forces the workflow.

You're right about Vanta re-ticketing causing duplicate alerts - that's a sneaky one! We added a check for the resource identifier string (like the specific AWS ARN) combined with the finding title's hash to catch those cases. It adds a few lines of logic but stops the dupes.

And totally agree, even with the occasional duplicate, the automated workflow is still the win. It moves the alert from a passive dashboard to an active queue someone has to acknowledge, which changes everything 😅

You're missing the actual payload construction, which is where most people mess up. The dedupe key needs to be at the top level, and you need to handle missing resource data.

```python
pd_payload = {
"event_action": "trigger",
"deduplication_key": finding['id'],
"payload": {
"summary": f"Vanta: {finding['title']}",
"source": finding.get('resource', {}).get('name', 'vanta'),
"severity": "critical",
"custom_details": finding
}
}
```

Also, you'll need a separate loop to close incidents for resolved findings, or they'll stay open forever.

You added a "client_url" field, but the PagerDuty Events API v2 spec doesn't actually accept that. It only accepts `client` and `client_url` for the *legacy* v1 events. So you're giving people copy-paste code that'll be silently ignored.

And you're still hardcoding "critical" as the severity. Vanta findings have their own severity levels. You're tossing that data out and making everything critical, which is a great way to get your alerts ignored. Map it, don't default to the noisiest setting.

Excellent catch on both points, especially the client_url spec mismatch - that's a subtle but important detail that'll leave people wondering why their links aren't appearing.

For the severity mapping, you're absolutely right. Vanta's `risk_level` field is crucial to preserve. A simple mapping usually works:

```python
severity_map = {
'HIGH': 'critical',
'MEDIUM': 'error',
'LOW': 'warning'
}
pd_severity = severity_map.get(finding.get('risk_level'), 'info')
```

Though I'd add a caveat: PagerDuty's severity field is just a string, so you need to align this mapping with how your team's escalation policies are configured.

Yeah, mapping the severity properly is key. That default "critical" is just noise pollution.

But I'd go a step further and make the mapping configurable. Our team treats Vanta MEDIUM as `error` for on-call, but QA wants it as `warning`. A flat dictionary in the code gets brittle fast. Put it in the config or environment.