Documentation Index

Fetch the complete documentation index at: https://help.nucleussec.com/llms.txt

Use this file to discover all available pages before exploring further.

Jira Ticketing Integration

  • 9 minute(s) read
Prev Next

Overview

The Jira ticketing connector provides bidirectional communication between Nucleus and Jira for performing tasks like:

  • Manually create ticket(s) from findings in Nucleus.

  • Create ticketing automation rules to eliminate manual efforts and streamline remediations by automatically generating tickets for high priority vulnerabilities based on criteria you customize.

  • View the latest ticket updates and add comments in real-time from within the Nucleus UI.

  • Update tickets as new finding instances are discovered or remediated.

  • Automatically close tickets when all instances of a finding have been remediated.

This article contains the following topics on how to configure the Jira ticketing connector to address these and other, more advanced use cases:

Creating a Jira Connector

The first step in configuring integration between Nucleus and Jira is to create a Jira connector in your Nucleus project.

Follow the steps below to create a new Jira connector in Nucleus:

  1. Open your Project, then navigate to Integrations > Connector Setup.

  2. Click the Jira button, found in the Issue Trackers section near the bottom of the page.

  3. Enter the URL to your organization’s Jira:

  4. Select an authentication method for your Jira connector:

    Best Practice

    Nucleus recommends using OAuth 2.0 for Jira integrations whenever possible. This method provides stronger security controls, improved performance and easier credential management compared to legacy authentication options.

    1. OAuth 2.0 (Recommended): Best for security and performance

    2. OAuth 1.0a (Legacy): Deprecated and not recommended for new integrations

    3. Basic Authentication / PAT: Limited use cases

    For further setup instructions, refer to:

  5. After successfully connecting to Jira, click Save & Finish.

Setting Connector Defaults

Setting connector defaults helps streamline the creation of Tickets and Ticketing Rules by prepopulating options with the most commonly selected values.

Connector Defaults

Settings configured here serve as defaults for all ticketing rules and manual tickets created with this connector. Individual automation rules can override these defaults as needed - look for the same options when configuring a rule.

Follow the steps below to set defaults for a Jira connector:

  1. In Project Administration > Connector Setup, click the Edit button on the connector you wish to set defaults.

  2. Select the Set Defaults (Optional) tab, then click Sync Fields.

  3. Select a default Jira Project and Issue Type to reveal all available options for that Project and Issue Type:

    1. Toggle the checkboxes under Default Summary and Default Description to set defaults on the content to include in the corresponding fields in Jira.

    2. Common Jira fields and Custom Fields for supported field types are listed below, allowing you to set default selections and/or text. Fields with an info icon next to them support Dynamic Fields. For more information, refer to the section below on Dynamic Ticketing in Jira.

  4. Enable auto-close for manually created tickets

    1. When enabled, tickets created manually will be automatically updated and transitioned to the selected closed status when all associated findings are remediated.

    2. Auto-close occurs during ticketing automation processing, which runs on scan update or ingest events.

  5. Set ticket status to - Select the Jira status that tickets will transition to when auto-closed (for example, Done or Closed).

  6. Do not close tickets for temporary status changes - Prevents tickets from closing during temporary or non-final status changes. Tickets will close only when findings reach a fully remediated state.

  7. When finished setting defaults, click Save & Finish.

CSV Attachment Configuration

The CSV Attachment Configuration section controls the content of CSV file attachments on tickets.

To configure CSV defaults:

In Project Administration > Connector Setup, click the Edit pencil on the connector you wish to configure.

Select the Set Defaults (Optional) tab.

Expand the CSV Attachment Configuration section.

Configure your preferred defaults, then click Save & Finish.

Setting

Default

Description

Include Remediated Instances

Enabled

When enabled, CSV attachments include all finding instances regardless of remediated status. When disabled, remediated instances are excluded entirely, showing only actionable items.

Tip: Disable "Include Remediated Instances" when remediation teams prefer to see only items requiring action, making progress clear from update to update.

Creating Tickets Manually in Nucleus

Manual ticket creation provides the ability to create ticket(s) for a unique finding as a whole, or for a specific subset of finding instances. Refer to the article on Manual Ticket Creation for an overview on how to create a manual ticket in the Nucleus UI.

Creating Tickets Using Automation Rules

Ticket Automation Rules are a powerful tool for streamlining and scaling your vulnerability management workflows, ensuring the high risk vulnerabilities according to your organization’s criteria are put in the hands of the right team with the right information to take immediate action.

Follow the steps below to create a Ticketing automation rule:

  1. From a project in Nucleus, navigate to the Automation page, and then select the Ticketing & Issue Tracking tab.

  2. Click Add Rule.

  3. On the 1. Rule Details tab:

    1. Enter a Rule Name.

    2. Optionally enable Include Project In Title under Options.

    3. Configure the Vulnerability Criteria and Asset Criteria that should trigger this rule.

    4. Under External System, use the System dropdown to choose the ticketing system (for example, JIRA). This determines the fields available to Group By.

    5. Under Ticket Grouping, use the Group By picker to choose how findings should be grouped into tickets. Unique Finding is selected by default; add additional groupings (for example, Severity or Instance Assignee) to split tickets further. At least one grouping is required; multiple groupings can be combined. For details, see Ticket Grouping article.

    6. Click Next.

  1. On the 2. System Configuration tab:

    1. Select a Jira connector from the Connection dropdown to the Jira instance that Nucleus should ticket to.

    2. Select the Jira Project.

    3. Click Sync Fields to pull the latest project and custom-field metadata from Jira.

    4. Complete the remaining fields (such as Issue Type, Summary, Description, Priority and any custom fields).

    5. Expand CSV Attachment Configuration if you want to override the connector default for including remediated instances in CSV attachments. Click Restore Defaults to restore from override.

    6. Click Next.

  1. On the 3. Advanced Settings tab, optionally:

    1. Enable Nucleus Bot Comments so Nucleus will post comments on the ticket when instances are added or mitigated.

    2. Enable auto-close of tickets. If auto-closing, choose the Closed Ticket Status that Nucleus should set when all vulnerabilities on the ticket have been mitigated. Optionally enable Do not close tickets for temporary status changes to keep tickets open when mitigation is temporary.

    3. Enable Run this rule on save to execute the rule immediately upon saving, in addition to running it on future ingestions.

  2. Click Save & Finish.

Dynamic Ticketing with Jira

Dynamic Ticketing is Available as an Opt-in Feature

Dynamic fields in ticketing automation rules and manual external ticket creation are currently offered as a beta product. Customers must opt-in to using these features. Please contact support or your Customer Service Representative to enable for your organization.

The Jira ticketing connector supports the use of Dynamic Fields for customizing ticketing automation workflows and enriching ticket contents with additional finding and threat intelligence attributes. Based on the Nucleus Dynamic Field Ticketing Language, users can leverage Dynamic Fields when setting connector defaults, manually creating tickets, or as part of ticketing automation rules.

Fields that support the use of Dynamic Fields are indicated by an ‘info’ icon as shown in the example below:

Dynamic Fields are specified using a standard moustache templating format, where you encapsulate the name of the dynamic field in double curly braces.

Examples:

  • {{finding.instance.assignee}}

  • {{finding.cvss}}

Most Dynamic Fields represent information associated with the unique finding, like finding.cvss, and do not vary across finding instances. Unique-level Dynamic Fields are used purely to enrich tickets with additional finding information. Some Dynamic Fields, like finding.instance.assignee and finding.severity, can have different values across instances of the unique finding. When using instance-level Dynamic Fields, instances are automatically grouped and ticketed individually for each distinct value of the Dynamic Field.

For a complete list of Dynamic Fields, see Dynamic Field Ticketing Language.

Common Use Cases for Dynamic Fields

Common use cases for Dynamic Fields include:

  • Dynamically grouping tickets based on the Assigned User on finding instances and assigning tickets created to their corresponding user in Jira.

  • Dynamically grouping tickets by Severities on finding instances.

  • Enriching custom fields in Jira with additional finding information like Scan Type, CVSS Score or threat intelligence attributes from Nucleus Insights.

The following sections walk through how to build automation rules for these use cases and the resulting ticketing behavior.

Group and Assign Tickets based on Nucleus Assignee

Scenario

We want to create a simple rule to create tickets for all discovered findings, but want individual tickets for each assigned Nucleus user containing only the instances they are assigned to. We will use the following vulnerability containing 3 instances with mixed severities assigned to 2 different users:

Create the Ticketing Automation Rule

Follow the steps below to create a Ticketing Rule that will ticket all vulnerabilities, grouped by the Assigned User in Nucleus:

  1. Navigate to Automation > Ticketing & Issue Tracking tab, then click Add Rule.

  2. Enter a Rule Name, then click Next.

  3. Select a Jira connector from the System dropdown box.

  4. Select the Jira Project, and then click Sync Fields to synchronize any custom fields.

  5. For the Assignee field, enter {{finding.instance.assignee}}, then click Next:

  6. Click Save & Finish.

Resulting Outcome

When the rule is processed following ingestion, we see there are 2 tickets created, one for each Assigned user:

Inspecting the CSV attachment on the highlighted ticket above, we see it contains details for the 2 instances assigned to ‘Nucleus user’:

Group tickets by Assignee and Severity

Scenario

Continuing from the previous example, we noticed that the ticket for ‘Nucleus user’ contains mixed severities. To ensure that Critical vulnerabilities can be prioritized and remediated independent of lower severity vulnerabilities, we want to create a ticketing rule that will group instances not only by Assigned user, but also by severity.

Create the Ticketing Automation Rule

Follow the steps below to create a Ticketing Rule that will ticket all vulnerabilities, grouped by Assignee AND severity:

  1. Navigate to Automation > Ticketing & Issue Tracking tab, then click Add Rule.

  2. Enter a Rule Name, then click Next.

  3. Select a Jira connector from the System dropdown box.

  4. Select the Jira Project, and then click Sync Fields to synchronize any custom fields.

  5. For the Assignee field, enter {{finding.instance.assignee}}, then click Next:


  6. Click the dropdown for Priority and select the Dynamic Field {{finding.severity}}:


  7. Click Save & Finish.

Resulting Outcome

This time when the rule is processed following ingestion, we see there are 3 tickets created:

The ‘Nucleus user’ now has individual tickets corresponding to the different severity levels on instances assigned to him. This also highlights the expected behavior when using the {{finding.severity}} to set values on the Jira Priority field:

  • If the Nucleus severity matches the name of a Priority level in Jira, it will be set to that value.

  • If the severity does NOT match the name of a Priority level in Jira, as shown with the ‘Critical’ vulnerability above, it will be set to the default Priority as specified in your Priority Scheme:

NOTE

Dynamic Fields evaluated at the instance level will ALWAYS split tickets on distinct value, regardless of the field in Jira they are mapped to. For example, mapping {{finding.severity}} to a custom label field rather than priority would still split tickets on distinct severity values.

Frequently Asked Questions

What does "No token was returned" mean after I click Connect to Jira?

If you received an error message during setup that says "No token was returned", this is an indication that during the connection process, when Nucleus attempted to retrieve a valid OAuth token from Jira, the response did not contain any tokens. This could possibly be due to a network error or due to another system sitting in between Nucleus and Jira and preventing connections from being established. In this situation it's unlikely that Nucleus was able to establish a connection to the Jira server at all.

What does "No token was returned, Jira replied with: signature_invalid" mean after I click Connect to Jira?

This error message is an indication that during the connection process, when Nucleus attempted to retrieve a valid OAuth token from Jira, the Jira server replied with an error stating that the provided OAuth signature was invalid. This is normally due to an issue with the way that the Jira server was setup, such as a reverse proxy rewriting HEAD requests to GET requests or not passing through the correct host header. Refer to this article for troubleshooting steps.