Jira

Jira

Guard's Jira integration enables automatic and manual creation of vulnerability tickets, bidirectional status synchronization, and configurable workflow transitions. This guide walks you through the setup process and covers the full set of features available once the integration is active.

Prerequisites

Before beginning the integration setup, ensure you have:

  • Access to create API tokens in your Atlassian account

  • A designated Jira project (or projects) for security vulnerabilities

Getting Started

To begin setting up your Jira integration, log into Guard and click Integrations in the left sidebar. Click Add Integration, select the IT Service Management category, and choose the Jira tile.

Jira Configuration

Jira configuration is a three-step process: authentication, project configuration, and transition mapping.

Step 1: Authentication

Before entering credentials in Guard, you will need to gather three pieces of information from Jira.

Jira URL — Log into your Jira instance and copy the base URL from the address bar. It will be in the format https://your-domain.atlassian.net. Do not include any additional path information like /jira or other extensions.

Email — The email address associated with the Atlassian account that will own the API token. You can find this by clicking on your profile icon in Jira.

API Token — Create an API token through Atlassian. The account that creates the token must have the following permissions on the target Jira project(s):

  • BROWSE_PROJECTS

  • CREATE_ISSUES

  • EDIT_ISSUES

  • ADD_COMMENTS

  • RESOLVE_ISSUES

  • EDIT_OWN_COMMENTS

To create the token, go to your Atlassian account at https://id.atlassian.com/manage/api-tokens and click Create API Token. Give it a meaningful label such as "Guard Integration." Copy the token immediately — you will not be able to view it again after closing the dialog. More on Atlassian API tokens can be found here.

Enter your Jira URL, Email, and API Token in Guard's authentication dialog and proceed to the next step.

Step 2: Project Configuration

Once authenticated, configure how Guard sends tickets to Jira:

  • Display Name — A display name for this integration (e.g., "Security Team Jira").

  • Project — Select from the Jira projects accessible with your API token. You can search for projects if your Jira instance has many.

  • Issue Type — The Jira issue type Guard will use when creating tickets (e.g., Bug, Task, Story). Subtask types are excluded.

  • Minimum Severity — The severity threshold for automatic ticket creation. Options are Critical, High, Medium, Low, and Informational. Only vulnerabilities at or above this level will trigger automatic tickets.

  • Auto-Create Tickets — When enabled, Guard automatically creates a Jira ticket whenever a new vulnerability meeting the severity threshold is discovered.

Step 3: Transition Mapping

The final step configures how Guard transitions Jira tickets when vulnerability statuses change. Jira workflows often require tickets to move through specific statuses in sequence (e.g., a ticket cannot jump directly from "Open" to "Done" — it may need to pass through "In Progress" first). Guard lets you define these transition paths so it can move tickets through your workflow automatically.

You will configure two transition paths:

  • Open → Close — The sequence of Jira status transitions Guard follows when closing a ticket (e.g., Open → In Progress → Done). This is used when a vulnerability is remediated, accepted, or rejected in Guard.

  • Close → Open — The sequence Guard follows when reopening a previously closed ticket (e.g., Done → In Progress). This is used when a remediated vulnerability is redetected or manually reopened in Guard.

Guard suggests default transitions based on common Jira status names. If your project uses custom statuses, adjust the transitions to match your workflow. The available statuses are pulled dynamically from your selected Jira project.

Click Connect to complete the setup.

Multiple Templates

You can configure multiple project templates within a single Jira integration. Each template has its own project, issue type, severity threshold, auto-create setting, and transition mappings. This allows different Jira teams to receive tickets with different configurations from the same Guard integration.

Ticket Lifecycle

Once configured, Guard manages the full lifecycle of Jira tickets as vulnerability statuses change.

Automatic Ticket Closing

When a vulnerability status in Guard changes to Remediated, Accepted (Ignored), or Rejected (Deleted), Guard automatically transitions the linked Jira ticket through your configured Open → Close path. Guard also adds a comment to the ticket that includes:

  • The closure reason (Remediated, Auto-Remediated, Rejected, or Accepted)

  • The username of the person who resolved the vulnerability

  • A link back to the vulnerability in Guard

Automatic Ticket Reopening

When a previously closed vulnerability is redetected by a scan or manually reopened in Guard, Guard transitions the linked Jira ticket through your configured Close → Open path and adds a comment indicating the reason (Redetected or Manual).

Label Synchronization

Vulnerability tags in Guard are synced to Jira labels. Labels are added when tickets are created and updated whenever the vulnerability's tags change. Labels are sanitized to meet Jira requirements (alphanumeric characters, hyphens, and underscores only).

Managing Tickets

Guard provides several actions for managing the relationship between vulnerabilities and Jira tickets. These are available under the More Actions dropdown on any vulnerability.

  • Create New Ticket — Manually creates a Jira ticket for the vulnerability in the project of your choosing. This is available whether or not auto-create is enabled.

  • Associate Existing Ticket — Links an existing Jira ticket to the vulnerability by providing the ticket ID.

  • Disconnect — Unlinks a Jira ticket from the vulnerability without deleting the ticket in Jira.

Once a ticket is linked, the vulnerability drawer in Guard displays the ticket ID, status, assignee, and a direct link to the Jira issue.

What Information Goes Into Jira Tickets

When Guard creates a Jira ticket, it includes comprehensive vulnerability information to help your team understand and remediate the security issue.

Ticket Title

The ticket title displays the vulnerability title, falling back to the risk name if no title is set.

Ticket Description

The description field contains detailed information formatted in Jira markup:

  • Chariot Link: A direct link to view the vulnerability in Chariot.

  • Severity: The severity level of the vulnerability (Critical, High, Medium, Low, or Informational).

  • Assets Impacted: A table listing all affected assets with their DNS name and asset identifier.

  • Vulnerability Definition: The complete vulnerability definition including technical details, impact assessment, and remediation recommendations. Content is automatically converted from markdown to Jira markup format.

  • Additional Evidence: If evidence has been collected, text-based evidence is included directly in the description. Binary evidence files are attached separately.

Attachments

Guard automatically attaches relevant files to the Jira ticket:

  • Screenshots: Images referenced in the vulnerability definition or evidence are uploaded as attachments.

  • Evidence Files: Binary evidence that cannot be displayed as text is attached with the format "evidence-[vulnerability-name]".

  • Proof Files: If proof data exists, it is attached as "proof-[vulnerability-name]".

If you need further assistance, please contact us at support@praetorian.com.