Ticket Content and Structure
When creating a ticket on a vulnerability in the Vulcan Platform, the description field is automatically populated with all the necessary and relevant information, depending on the integrated ticketing system and available ticket fields of that system.
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.
Example of a JIRA ticket generated by the Vulcan Platform:
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, the ticket is called after the unique vulnerability name.  |
The Vulnerability |
|
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:
|
References |
|
Additional Info |
|
Attachments (CSV or .zip files) |
 |
Notes
*The level of information covered in the ticket depends on the availability of the information in the Vulcan Platform and the capabilities of the integrated ticketing system. 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, the ticket's settings, and the capabilities of the integrated ticketing system.
For example, in manually created JIRA tickets, if a ticket is opened on multiple unique vulnerabilities, the "Separation to tickets" configuration becomes available with the following options:
Option 1: Separate tickets per unique vulnerability
Option 2: Aggregate all content to a single ticket (up to 100 vulnerabilities per ticket)
For both manually created and automated Jira tickets, you can also utilize the Dynamic Properties feature to populate the Assignee field with predefined asset owners.
Also in Jira, In the Playbook ticket configuration, the "Update ticket behavior" configuration is available:
Option 1: Open a ticket and update it with subsequent discoveries
Option 2: New ticket per set of assets discovered
ServiceNow vs. JIRA Ticket Capabilities
Feature | ServiceNow – Problem and Problem task option | ServiceNow – Incident table option | JIRA |
Ability to open a ticket for every unique vulnerability | Yes. The ticket can be opened in the Problem table. | Yes. The ticket can be opened in the Incident table. | Yes, the ticket will be opened as Task/Epic/or any other JIRA option. |
Ability to have the affected assets related to the ticket. | Yes. In the Problem table, the affected assets will be opened as Problem Task under the Problem ticket. | Yes. In the Incident table, the affected assets will be attached as CSV. | Yes. the affected assets will be attached as CSV. |
Ability to automatically close the ticket for each of the affected assets. | Yes. Each affected asset will be as a Problem Task. When the affected asset will be remediated, the problem task will automatically be closed. | No. The ticket will have an updated CSV for every update in the affected assets. But the ticket will be closed only when all the affected assets will be remediated. | No. The ticket will have updated CSV for every update in the affected assets. But the ticket will be closed only when all the affected assets will be remediated. |