We've got Lacework alerting to Slack and PagerDuty, but our change process requires a Jira Service Management ticket. Need to automate creating a JSM ticket for every High/Critical Lacework finding.
Tried their webhooks, but the JSON payload doesn't map cleanly to JSM fields. Also need it to only fire for new findings, not every re-evaluation.
Current workaround is a clunky Python script that:
1. Polls Lacework APIs
2. Filters for new High+ alerts
3. Uses Jira REST API to make tickets
It's fragile. Want something more direct.
Has anyone built a reliable integration? Key requirements:
* Must populate JSM custom fields (priority, summary, description).
* Should avoid duplicate tickets for the same finding.
* Needs to attach relevant evidence (like the Lacework alert ID).
Looking for:
* Example webhook transformation logic (Node or Python).
* How you handled authentication (API keys, service accounts).
* Any pre-built connectors or tools you used.
// chris
metrics not myths
Been there with the clunky script approach, Chris. The webhook mapping is a pain because Lacework's payload is so nested. We ended up using a small AWS Lambda (Python) as a transformer.
It listens for the Lacework webhook, flattens the key bits like alert ID and severity into a format JSM expects, and adds a hash of the finding as a custom field to prevent dupes. For auth, we store the Jira service account API key in AWS Secrets Manager. The lambda fetches it on execution.
One gotcha: Lacework will send the same finding on re-evaluation. We stamp a "last_processed_time" in a DynamoDB table against the alert hash and only create a ticket if it's truly new (like, over 24 hours old). Stops the ticket spam. I can share the gist of the flattening logic if you're on Python.
it worked on my machine
Lambda as a transformer is solid. For de-duping, a hash is smart, but we've also added a check for Jira's "external ID" custom field. If we see the same Lacework alert ID there, we just add a comment to the existing ticket instead of creating a new one. Saves the DynamoDB table.
On auth, we went with a Jira API token in an Azure Key Vault since our shop is Azure-heavy. The lambda grabs it at runtime. If you're in AWS, Secrets Manager is definitely the way to go.
The flattening logic is the tedious part. Main trick? Use `json_normalize` from pandas in your Python lambda - it saves a ton of nested looping to get at the details like resource ID and recommendation.
Automate everything.
DynamoDB for deduping works but adds cost and latency. We skip it entirely.
We hash the finding's composite key (alertId + resourceId + evalGuid) and set it as the Jira ticket's `externalId`. On any incoming webhook, we first query Jira by that custom field.
- If ticket exists, we append a new comment with the updated timestamp.
- If not, we create.
No external state needed. Query is cheap, and Jira becomes the source of truth for ticket state. One lambda, no DDB table.
Metrics don't lie.
Great approach! Using Jira itself as the dedupe source is clever and cuts out an extra service. We did something similar but added a fail-safe for the query step.
If the Jira query times out or is slow, the lambda could get throttled. We added a simple in-memory cache of recently processed hashes (last 10 minutes) as a fallback. It's not perfect, but it prevents a brief Jira API hiccup from accidentally spawning duplicate tickets during a spike in alerts.
That's a neat detail on using `alertId + resourceId + evalGuid`. We found that `alertId + resourceId` was enough for our vuln findings, but I can see why you'd include the evalGuid for compliance events.
Data doesn't lie, but dashboards sometimes do.
Lambda as middleware just moves the fragility. You're still maintaining a custom transformer, plus now it's a black box running on someone else's dime.
What if Lacework changes their webhook schema again? Your lambda breaks. What if Jira's API changes? Your lambda breaks. You've swapped a script for a serverless function with the same core problem.
Polling the Lacework API might actually be more robust. You control the frequency and handle errors explicitly. A direct webhook expects the world to be perfect. It rarely is.
Doubt everything