Skip to main content
All CollectionsConnectorsTicketing ToolsJira Integration
Jira Intergation
Jira Intergation

Learn all about the JIRA bi-directional integration, opening JIRA remediation tickets, and closing JIRA tickets through the Vulcan Platform.

Updated over 3 months ago

Integration Capabilities

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

  • Opening a JIRA ticket per unique vulnerability

  • Adding all vulnerability and remedy information into the JIRA ticket

  • Attach the affected assets and remedies in a CSV file to the Jira ticket

  • Automatically update the JIRA ticket with subsequent discoveries on affected assets

  • Automatically close the JIRA ticket when all vulnerability instances are remediated

  • Visibility into the JIRA ticket status through the Vulcan Platform

  • Accessing Vulcan Campaign through the JIRA ticket

  • Accessing the JIRA ticket through the Vulcan Campaign

Ticket Lifecycle

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

  1. On the Vulcan Platform side, a campaign is created on the Campaigns page. A single campaign can contain multiple tickets (based on the ticket's settings). The Campaign allows you to fully monitor the status of the associated JIRA ticket(s) and the entire Campaign's progress.

  2. On the JIRA side, a ticket (or more) is created containing all the relevant vulnerability information. The ticket is fully manageable through the JIRA platform, just like any other regular JIRA ticket.
    ​The following ticket details/attributes are set in the ticket by default:

    1. The ticket status is set to the first available 'Open' status.

    2. The ticket description is populated with all the relevant vulnerability and remedy information.

    3. The label 'vulcan_generated' is set in the ticket's Details. This label can also be used to define Vulcan-Jira-specific status transitions and limit user access.

    4. The ticket Reporter is set as the integration user (configurable when creating the ticket).
      ​Read about how the attributes above help you create the JIRA status transition flow to enable the Vulcan-JIRA bi-directional integration.

Transitioning ticket status to DONE

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

Status transition

Condition to be met

"Open" (initial ticket opening)

The ticket status in JIRA is set to 'Open/To do' when creating a JIRA remediation ticket through the Vulcan Platform.

From "Open/Todo"
to "Done"

For manual and automated tickets:

  1. The Jira status transitions must be configured to allow the Vulcan Platform to close the tickets.

  2. The option to "Mark issue as done through Vulcan" is enabled on the JIRA Connector setup page.

  3. All vulnerability instances in the campaign ticket(s) are fixed or archived (the info on the vulnerability status is received through the integrated connector).

For automated tickets only:

  1. The option to "Mark issue as Done" is enabled on the Vulcan Playbook setup page.

Creating JIRA status transitions for the Vulcan Integration

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:

  1. The issue must have the label 'vulcan_generated'

  2. The issue must have a reporter that equals the same person who activated the Vulcan connection.

See an example below:

Opening a Jira Ticket

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

Take Action on Vulnerabilities

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

  1. Go to Vulnerabilities

  2. Select the relevant vulnerability(ies) on which you wish to open the JIRA remediation ticket.

  3. Click on Take Action and select JIRA.

  4. Review all the available settings in the JIRA form and modify them as needed. When opening a ticket manually, you can also change the following options that are available only for manually created tickets:

    1. Select Assets to Patch

    2. Select Remedies to apply
      ​Example of manual JIRA ticket form

  5. You can also utilize the Dynamic Properties feature to populate the Assignee field with predefined asset owners.

  6. When ready, click Open ticket.
    The ticket creation generates a Vulcan Campaign that contains the created JIRA tickets.

  7. To track and manage the generated campaign status, go to Campaigns.

Creating a JIRA Playbook (Automation)

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.
​

Ticket Content and Structure

Ticket Information

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.

Information Category

Information Included*

Vulnerability name

By default, every JIRA ticket is called after the unique vulnerability name.

The Vulnerability

  • Vulnerability max risk score

  • CVSS score

  • Unique Vulnerability description

  • Vulnerability ID in vendor platform

  • Affected assets**

  • Vulnerability instance details

  • Exploitability

  • Attack vector

  • High Asset-impact tags (if none exists, other non-high-impact tags are listed)

The Remedies***

The ticket may include more than one remedy source. In this case, the remedies are order-listed. A piece of single remedy information in the ticket includes:

  • Remedy title by source

  • Remedy description

  • Security fix(es)

  • Bug Fix(es)

  • Link to source of security advisory

  • Affected packages

  • Link to download patches

References

  • CVEs (including reference link)

  • CWEs (including reference link)

Additional Info
​

  • Link to the Vulnerability page on the Vulcan Platform (optional)

  • Ticket trigger source (automation or manual) -

  • Playbook ID (only if the source is "automation")

Attachments (CSV or .zip files)

  • Remedies summary

  • Affected assets summary

  • Vulnerabilities Summary

Notes

*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:

Ticket Settings

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:

  • Option 1: Separate tickets per unique vulnerability

  • Option 2: Aggregate all content to a single ticket (up to 100 vulnerabilities per ticket)

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

  • Option 1: Open a ticket and update it with subsequent discoveries

  • Option 2: New ticket per set of assets discovered

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).

Closing Vulcan Campaigns and JIRA Tickets

Campaigns and tickets can get closed in two ways:

  1. Manually by the user (Recommended for POC and testing only)

  2. Automatically by the Vulcan Platform (Recommended for production)

Closing Campaigns and tickets manually by the user (Recommended for POC and testing only)

  1. Go to Campaigns

  2. Click on the JIRA Campaign you want to close

  3. Click on "Mark as Done".

    This action closed the JIRA-associated tickets if the integration supports it.

Closing Campaigns and tickets automatically by the Vulcan Platform (Recommended for production)

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:

  1. The status of the affected assets, for which the vulnerability instance is fixed, changes to "Fixed" on the Vulcan Platform and in open campaigns.

  2. The associated JIRA ticket(s) creates a new Assets CSV attachment with the updated list of affected assets.

  3. Once all the affected assets are moved into a fixed state and the Campaign is completely remediated, the status of the Campaign changes to "CLOSED" and moves to the Closed tab.

  4. It is possible to configure the Vulcan platform to change the JIRA ticket status to "DONE" when it identifies that all the vulnerability instances in the ticket are fixed/archived. Vulcan allows you to define the desired 'Done' status for each Playbook. To do so, see the conditions to be met under the following section "Configuring the Vulcan Platform to transition the JIRA ticket status to DONE".

Configuring the Integration

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

FAQ

What settings and information can I modify when creating the JIRA remediation ticket through the Vulcan Platform?

The following are some of the main settings available for modification upon creating a JIRA ticket:

  • Project

  • Assignee

  • Affected assets

  • Remedies to apply

  • Description

  • Issue Type (Epic, Story, etc.)

  • Mark Issue as Done

  • Separation of tickets (when relevant)

  • Choose 'Done' status

  • <Issue type> name

  • Ticket title

  • Priority

  • Due Date

    ...and more (depending on the available JIRA ticket configurations and method of creation; manual or automated)

What does the "Mark issue as Done" option in Playbooks mean?

In the Automated Playbooks and Manual ticket opening Jira forms, a 'Mark issues as done' toggle option is enabled by default. A mandatory drop-down lets you select an option within the 'Done' status category when enabled. This option allows the Vulcan Platform to transition JIRA 'vulcan_generated' labeled tickets from Open to Done.

What are Jira's 'Done' status options, and why must you choose one in Vulcan?

The 'Done' status is the final stage of the issue/ticket lifecycle used to define resolution. Examples of 'Done' statuses are: Resolved, Rejected, Duplicated, etc. For instance, in the Vulcan Platform, you may want to mark issues as 'Done' when vulnerabilities related to a given Vulcan-generated Jira ticket are fixed, and the meaning could be 'Closed' or 'Resolved' in this case.

Does Vulcan support an 'in progress' status in Jira?

No. Jira admins need to configure Vulcan-specific transitions in their Jira environment, using the label vulcan_generated and limiting users that can report.

What happens to the Vulcan Campaign if the ticket is closed in JIRA for any reason?

If the JIra ticket is Closed/Deleted in JIRA, the ticket visibility available in the Vulcan Campaign will also change the status to CLOSED. However, the Vulcan Campaign stays in "Open" until all vulnerability instances are identified as FIXED/Archived through the integrated scanner connector.
​

Where can I see statistics about Jira tickets and campaigns?

You can see stats on tickets created in Jira on the Campaign Tracking Report in Vulcan Analytics (Reports).

  1. Go to Reports/Analytics.

  2. Enter the Campaign Tracking Report.

  3. Check the widgets that provide comprehensive stats on the campaign and tickets created through the Vulcan Platform.

Related Articles
Jira Connector
Vulcan Campaigns - Create, Track and Manage Remediation Campaigns
Sonatype Connector
Microsoft Azure Boards Connector
Submitting Exception Requests through ticket - Remediation Work Form User Guide
Did this answer your question?