The Vulcan-JIRA bi-directional integration allows streaming actions in both directions, from Vulcan to JIRA and vice versa. The integration capabilities are:

Once the Vulcan Platform creates a JIRA ticket (manually or automatically), two things happen:

The table below describes what conditions must be met to enable ticket status transition in JIRA from 'Open' to 'Done' through the Vulcan Platform.

You must create a JIRA transition allowing the Vulcan Platform to update the JIRA ticket status (from Open to Done). The transition should use rules that limit other users and issues from transitioning in the same way as the 'vulcan_generated' labeled tickets. The suggested rules are:

See an example below:

The JIRA integration lets you take action on vulnerabilities and open remediation tickets in JIRA directly through the Vulcan Platform. You can open tickets manually or create automation (Playbooks).
See Vulcan Campaigns - Create, Track, and Manage Remediation Campaigns

To open a JIRA ticket manually on a single vulnerability or more, follow the instructions below:

The automation Playbooks allow you to minimize response time and reduce mundane manual labor by automating remediation tasks and ticket opening based on business and security conditions by integrating the desired report/ticketing system in your organization.

First, make sure to learn how to create and manage automation. All automations are based on the same principles but with different settings and modifications, depending on the selected Remediation Action method. See Automation Playbooks.
​

When creating a ticket on a vulnerability in the Vulcan Platform, the description field is automatically populated with all the necessary and relevant information in the JIRA ticket.

Every ticket includes vulnerability information and relevant attachments. The ticket structure also varies based on the number of unique vulnerabilities the ticket is opened for and the ticket settings.
​

By default, once a ticket is opened, the information described in the table below is automatically shared in the "Description"/"Body" field of the integrated ticketing system in the same presented order. However, suppose a load of vulnerability information is highly extensive and lengthy. In that case, the Vulcan Platform automatically summarizes the information shared in the ticket's body and attaches the rest as CSV/zip files. For example, suppose the ticket is opened on many unique vulnerabilities. In that case, the respective remedies aren't shared in the ticket's body but instead summarized as an attachment in a CSV/ZIP file.

*The level of information covered in the ticket depends on the availability of the information in the Vulcan Platform. If a piece of info isn't in the ticket, it is either unavailable, missing from sources, or irrelevant.

**In manually created tickets, the number of affected assets depends on the selected "Assets to patch" configuration. For example:

**In automated tickets (playbooks), the number of affected assets meets the assets criteria defined in the playbook conditions. For example:

***In manually created tickets, you can select which remedy sources to include in the ticket. For example:

The structure of the ticket's content depends on the number of unique vulnerabilities in the ticket and the ticket's settings.
​
​In manually created JIRA tickets, if a ticket is opened on multiple unique vulnerabilities, the "Separation to tickets" configuration becomes:

In the Playbook ticket configuration, the "Update ticket behavior" configuration also becomes available:

The most common use case is to separate each ticket by unique vulnerability and update the ticket with subsequent discoveries. This way, each unique vulnerability will group every affected asset into a JIRA ticket, and each affected asset will be attached to the JIRA (in a CSV file).

Campaigns and tickets can get closed in two ways:

The Vulcan Platform updates the status of a vulnerability instance based on the daily information received and ingested through the vulnerability scanner/assessment connector. Based on the ingested data, the Vulcan Campaign updates the associated JIRA ticket and Vulcan Campaign progress as follows:

The Vulcan Campaign stays in "Open" status until all the vulnerability instances in the Campaign are identified as fixed or archived. Once the vulnerability instances (or part of them) are fixed/archived, then:

To set up the JIRA integration, follow the instructions in the Jira Connector User Guide.