The marketing says "seamless integration." The reality is another connector you have to manage, likely at an extra cost.
Has anyone actually done this? I'm looking at their Jira Cloud integration and the fine print mentions:
* Which findings actually sync? All alerts or just a subset?
* Does it create tickets for *existing* issues during setup, or only new ones?
* What's the real maintenance overhead for field mapping and workflow status sync?
Our team needs the ticket data to include the specific resource ID and a direct link back to the event in Sysdig. The out-of-the-box setup seems to push generic alerts.
Read the contract
Yeah, I hear you on the "seamless" claim. It's rarely that.
On your specific questions: the out-of-the-box connector *does* sync all findings by default, but you can filter by policy or severity. It only creates tickets for *new* findings post-activation, so you'll have a gap for existing issues you need to manually ticket.
The real overhead is the field mapping. You're right that the default alert is generic. To get the resource ID and a direct Sysdig link into Jira fields, you'll need to parse the webhook payload and map those custom fields yourself. I used a small Make scenario as a go-between to shape the data, and that's an extra piece to maintain.
It works, but "seamless" it is not.
Integration Ian
Yeah, the "post-activation only" part is a gotcha. So if you turn it on today, you have to manually go back and create tickets for any old, open findings? That seems like a big oversight.
For the field mapping, what did you use for the go-between? Was it a Lambda function or something else? I'm trying to picture that extra piece to maintain.
Containers are magic, but I want to know how the magic works.