JFrog Xray: Creating Jira Issues using webhooks in a breeze
By Shai Ben-Zvi
JFrog Xray offers an end-to-end security scanning solution covering the full development lifecycle of your artifacts. This includes vulnerability analysis, security and license compliance, artifact flow control, distribution and more. When Xray finds a security or a licence issue, it will trigger a violation for it. One of the most common use cases during the development cycle is to have the ability to track these issues using commonly used tools such as Jira, and Xray Webhooks allow you to do that.
First, what’s a webhook?
A Webhook is an API concept which is used to alter web requests behaviors with custom callbacks, used by third party users, developers or programs which are not necessarily affiliated with the originating website or application. This can also be referred to as “Reverse API”.
Let’s say that we have a violation triggered by Xray, and we have an Xray policy with a watch that’s configured to send a Webhook to a specific third party application. To make the .json file that’s automatically created readable and usable by the third party application, we can use a simple script that can parse the data and display it in a Jira ticket or even a Slack message.
5 easy steps to implement Xray webhooks that work with Jira
Here’s what we’ll need to do this:
Create a ‘light’ server which will know how to listen to remote requests.
Configure an Xray webhook that’s associated with a policy that will trigger it.
Understand the structure of an Xray Webhook .json file, in order to parse the information correctly. (see Infected Files Structure snippet in section below)
Once we’re able to parse the information, we need to define what we want to send to our JIRA server and what information the issue will contain. (see Create Jira from Xray Handler snippet in section below)
Implement the Jira server interaction with this information.
Why is Go the best way to go?
Go is a SUPER easy language to use! With just a few lines of code, we can easily create a server that’s up and running in no time, and knows how to listen to HTTP requests. From my experience, compared to other languages, this is much easier to do using the Go programming language.