Skip to main content

​
Overview

ZeroPath integrates with Jira to push security findings as Jira issues and sync status changes back. When a Jira issue is resolved, the corresponding ZeroPath finding is automatically marked as resolved. Both Jira Cloud and Jira Data Center (self-hosted) are supported.
An organization can connect either Jira Cloud or Jira Data Center — not both at the same time. Disconnect the existing integration before switching between the two.
Connecting Jira requires the Integration Create permission, which is restricted to organization admins. This applies to all three connection methods (OAuth, API Token, and Personal Access Token).

​
Setup

1

Navigate to Integrations

Go to Settings → Integrations in the ZeroPath dashboard.
2

Connect Jira

Click “Connect Jira” and authorize ZeroPath in the Atlassian consent screen.
3

Auto-Configuration

ZeroPath automatically detects your Jira Cloud instance and default project.
All three methods register a webhook in your Jira instance for bidirectional sync. OAuth connections use the dynamic webhook API. API token and Personal Access Token connections use the legacy Jira admin webhooks API, which registers the webhook automatically when the user is a Jira admin. If auto-registration is not possible (for example, because the PAT belongs to a non-admin user), the setup flow returns the webhook URL and secret so you can create it manually in Jira’s admin settings.

​
Webhook Events

The ZeroPath webhook uses the following Jira events: The comment events are optional but recommended. When enabled, ZeroPath uses ticket comments to intelligently classify closed tickets as Resolved, False Positive, or Accepted Risk instead of always defaulting to Resolved.

​
Manual Issue Export

From any finding in the ZeroPath dashboard:
  1. Click “Export to Jira” on the issue detail view.
  2. Select a Jira project, issue type (Bug, Story, Task, etc.), and optionally an epic and assignee. Epics are available for all issue types, not just Tasks.
  3. ZeroPath creates the Jira issue with full vulnerability details — title, description, affected file, severity, CVSS score, CWEs, code snippet, and patch link if available. For secrets findings, the title, description, and code snippet are automatically redacted so that cleartext secret values are never written into Jira tickets. The title is replaced with a generic label identifying only the affected file, and the description is withheld entirely.
If the selected issue type does not support a parent link (for example, Epics cannot have a parent in Jira’s hierarchy), ZeroPath automatically retries without the epic link so the issue is still created successfully. The Jira issue key is linked to the ZeroPath finding for bidirectional tracking.

​
Bulk Export

You can export multiple findings to Jira at once:
  1. Select the findings you want to export from the issues list.
  2. Choose “Export to Jira” from the bulk actions menu.
  3. Select a Jira project, issue type, and optionally an epic and assignee. You can select “None” to explicitly clear the epic selection.
  4. If a Jira template is configured, you can toggle “Use Jira Template” to apply it to all exported issues.
  5. ZeroPath creates Jira issues for all selected findings in batches. Titles, descriptions, and code snippets for secrets findings are automatically redacted in all created tickets.
Findings that have already been exported to Jira are automatically skipped. After the export completes, you will see a summary showing how many issues were exported, skipped, or failed.

​
Who Can Create Jira Tickets

Creating a Jira ticket writes into your Jira instance using the organization’s shared Jira credentials, so ZeroPath gates it on a per-repository permission — Create Jira Tickets — rather than on the org-wide integration connection. This permission lives in the Issue Tracker Export group of the Teams & Permissions system and is granted per team, so it also controls the bulk export flow. How the gate behaves depends on whether your organization has access control enabled:
  • Access control disabled (default). Every organization member can export findings to Jira. No per-team restriction is enforced.
  • Access control enabled. Organization admins can always export. Any other member can export a finding only if one of their teams holds the Create Jira Tickets permission on that finding’s repository — granted directly, through a tag, or organization-wide.
Bulk export applies the same per-repository check to every selected finding. Findings in repositories where you lack the permission are counted as failures and skipped, and the rest of the batch still exports.
Restricting ticket creation to admins. To limit Jira ticket creation to organization admins, enable access control and do not grant the Create Jira Tickets permission to any non-admin team. Admins always retain the ability to export; everyone else is blocked. Grant the permission to specific teams (or specific repositories via tags) to widen access as needed.
ZeroPath records single-finding export requests that pass its permission checks as jira.exportIssue actions in your organization’s audit log and bulk export requests as jira.bulkExportIssues actions. Each entry captures who initiated the request, the selected finding or findings, and the target Jira project. These actions record export attempts, including requests that Jira later rejects, so they do not by themselves confirm that tickets were created.
Automatic Ticketing runs as a system action from your organization’s saved configuration and is not subject to the per-user export permission. Control it by managing who can edit integration settings and by scoping each auto-ticketing config to specific repositories or tags.

​
Automatic Ticketing

Configure automatic issue creation for new findings:
  1. Go to Settings → Integrations, select Jira from the sidebar, and open Auto-Ticketing.
  2. Set a score threshold — only findings above this score create Jira tickets. Secret findings must also carry a confirmed verdict: a secret the scanner flagged but the validator has not confirmed creates no ticket, whatever its score. This prevents a ticket from asserting a leak that was never verified.
  3. Choose which scan types trigger tickets (Full Scan, PR Scan, SCA, etc.).
  4. Select the Jira project and issue type.
  5. Optionally select an epic to group auto-created tickets under. If a previously configured epic is no longer available in Jira, a warning is displayed so you can select a new one or clear the selection.
  6. Optionally configure auto-assignment, custom templates, and scope (all repos, specific repos, or repos matching specific tags).
Titles, descriptions, and code snippets for secrets findings are automatically redacted in all auto-created tickets, so cleartext secret values are never written into Jira.

​
SLA Due Dates

Enable Set due date from SLA to stamp each created ticket with the finding’s remediation deadline as the Jira due date — the earliest breach date across every SLA policy that covers the issue. This applies to both auto-created and manually exported tickets. If no SLA policy covers the finding, no due date is set.
The due date requires the selected issue type to expose a Due date field on its create screen. If it does not, ZeroPath warns you when saving the configuration and still creates tickets (without a due date). If Jira later rejects the due date for an individual ticket, ZeroPath retries without it so the ticket is still created.

​
Custom Templates

Auto-ticketing supports customizable title and description templates with variables:
  • {{severity}}, {{issueTitle}}, {{repositoryName}}, {{affectedFile}}, {{vulnClass}}, and more.
  • Custom Jira fields can be mapped to ZeroPath finding data or static values.

​
On-Demand Ticket Sync

Linked Jira tickets can drift out of sync with their ZeroPath findings — for example, if a webhook delivery is lost, a Jira workflow has no “done” transition, or inbound webhooks are not installed. The on-demand ticket sync feature lets you reconcile these tickets from the repository settings page.

​
Preview

  1. Open the repository, select Settings → Remediation, and click Review linked Jira tickets under Jira ticket sync. This section appears when the repository has linked Jira tickets.
  2. ZeroPath reads the live status of every linked Jira ticket (up to 200 per preview) and compares it against the finding’s current state.
  3. Each ticket is classified as one of:
    • In Sync — the ticket and finding already agree. A ticket is considered closed when Jira marks it as resolved (the resolution field is set) or when it reaches a terminal done-category status.
    • Will Close — the finding is closed but the ticket is still open, and a closing transition is available in the Jira workflow.
    • Will Comment Only — the finding is closed but the Jira workflow has no available closing transition, so only a comment can be posted. This also covers tickets parked in a green-category staging status (such as “Ready for Release”) that are not yet resolved in Jira.
    • Reopened in ZeroPath — the ticket appears closed in Jira but the finding has been reopened in ZeroPath. These are surfaced for awareness but not written to.
    • Sibling Conflict — multiple findings share the same ticket and disagree about whether it should be closed. These require manual resolution.
    • Unreachable — the ticket could not be read from Jira (expired token, permissions issue, etc.).
You can optionally filter the preview to a specific Jira project.

​
Sync

  1. Review the preview and select the tickets you want to sync. Each row shows the finding’s closure reason — Closed by a person, Marked non-exploitable by the scanner, Assessed by ZeroPath, Explicitly resolved, Archived by a person, Scan stopped detecting it, or Auto-closed when the repository was archived — so you can judge each closure before pushing it. Tickets closed by a human decision (manual triage, false positive, accepted risk), a scanner verdict (non-exploitable or assessed), or an explicit resolution are pre-selected. Tickets closed only because a scan stopped detecting the finding or because the repository was archived are shown but not pre-selected, so you can review them before syncing.
  2. Click Sync to push the selected statuses to Jira. ZeroPath transitions each ticket and posts a comment explaining the closure reason.
  3. If a finding also has a linked Linear issue, that issue is closed at the same time — the preview indicates when this will happen.
The comment ZeroPath posts when closing a ticket distinguishes between resolution types. When a finding was explicitly verified as fixed (for example, by a merged pull request), the comment confirms the fix and includes a link to the merged PR. When a finding was marked as non-exploitable through validation, the comment includes the validation assessment explaining why the finding is not exploitable. When a finding was not detected in a scan but not explicitly verified, the comment states that ZeroPath did not observe the finding and clarifies that this is not a verification the issue was fixed — only that it was absent from the latest scan results.
The sync re-derives the target status from the database at apply time, so a finding that changed between preview and sync is safely skipped rather than written incorrectly. Syncing requires the Issue Edit / Close permission.

​
Outbound Status Sync

When a ZeroPath finding is resolved or marked as non-exploitable, ZeroPath automatically pushes the status change to any linked Jira ticket. The ticket is transitioned to a closed state and a comment is posted explaining the resolution. This sync runs continuously in the background, so linked tickets stay up to date without manual intervention.

​
Bidirectional Sync

When a Jira issue’s status changes to Done, Resolved, Closed, or Completed, ZeroPath automatically:
  • Analyzes ticket comments to determine the appropriate status — Resolved, False Positive, Accepted Risk, or Non-Exploitable
  • If no comments are present or comment events are not enabled, the finding defaults to Resolved
  • If comments are present but the intent cannot be determined with confidence, the status change is skipped rather than defaulting to Resolved, preventing incorrect triage
  • Records who made the change and when
  • Logs the state transition in the finding’s audit trail
When the same Jira ticket is linked to more than one ZeroPath finding (for example, because a finding was carried forward across successive scans), closing the ticket resolves all linked findings at once. Duplicate webhook deliveries for a ticket that was already closed are automatically skipped — this includes findings that were closed because they are no longer detected in the latest scan, so those findings are never incorrectly re-triaged when Jira echoes their ticket closure back. ZeroPath selects the correct Jira workflow transition based on the target status. When marking a finding as Resolved, ZeroPath picks a completion transition (such as “Done”) and avoids cancellation-style transitions like “Won’t Do”. When marking a finding as False Positive or Accepted Risk, ZeroPath prefers a cancellation-style transition if one is available. This ensures your Jira workflow states accurately reflect the triage decision. When you change the status of multiple findings at once (for example, marking many issues as false positive), ZeroPath syncs each update to Jira with controlled concurrency to stay within Jira Cloud rate limits. If an individual ticket update fails, the remaining updates continue — partial failures are logged without blocking the bulk action. This sync is powered by a webhook registered in your Jira instance during setup.
Jira Cloud webhooks created via the dynamic API (used by OAuth connections) expire after 30 days. ZeroPath automatically renews them, but if sync stops working, reconnect the integration from Settings → Integrations to refresh the webhook. Webhooks created via the legacy admin API (used by API token and Personal Access Token connections when the user is a Jira admin) do not expire. When you reconnect, ZeroPath automatically removes any stale webhooks — including those registered under an outdated secret or a previous public URL — before creating a new one.

​
Confluence Access

The Jira Cloud integration also provides access to Confluence, since both products share the same Atlassian OAuth token. When Confluence is enabled, the AI AppSec Assistant can search and read your Confluence pages for security documentation, architecture context, and runbooks.
Confluence is only available with Jira Cloud connections (OAuth or API Token). Jira Data Center integrations do not support Confluence linkage.

​
Enabling Confluence

  1. Connect Jira using either the OAuth or API Token method described above.
  2. Once Jira is connected, a Confluence option appears in the integrations page. You can enable it directly from the Add Integration dialog with a single click — no additional authentication is required.
  3. Alternatively, select Confluence from the integrations sidebar and toggle Confluence Access on.
No additional authentication is required — Confluence reuses your existing Atlassian OAuth token.

​
Disabling Confluence

To disable Confluence access, select Confluence from the integrations sidebar and toggle Confluence Access off. This does not affect your Jira integration.

​
Auto-Fix PR Templates

When a finding has a linked Jira ticket, ZeroPath’s auto-fix templates can reference the ticket. You can use {jira_id}, {jira_title}, and {jira_url} placeholders in your PR title, PR description, branch name, and commit message templates to include the linked Jira ticket details in generated patch PRs. See Jira Ticket References in Templates for details.

​
Repository Deletion

When a repository is deleted from ZeroPath, all Jira tickets that were synced for findings in that repository are automatically closed before the repository is removed. This happens as a best-effort step — if closing a ticket fails, the repository deletion still proceeds. Tickets created for findings in other repositories are not affected.

​
Troubleshooting

Ensure the integration is connected in Settings → Integrations.
For OAuth connections, check if the Jira webhook has expired (30-day limit) and reconnect the integration to refresh it. For API token and Personal Access Token connections, verify the webhook was auto-registered (the setup response indicates this) or create it manually in Jira admin. Also verify the Jira issue key matches a ZeroPath finding (the link is created during export).
Check that the selected project and issue type exist in your Jira instance. Ensure required Jira fields are configured in the auto-ticketing settings.
  • Invalid Personal Access Token — Verify the token is active in your Jira profile under Profile → Personal Access Tokens. Tokens expire based on your Jira admin’s policy.
  • Version not supported — Personal Access Tokens require Jira Data Center 8.14 or later. Check your instance version in Jira Administration → System → System Info.
  • TLS certificate error — If your instance uses a self-signed or private CA certificate, paste the CA bundle (PEM) in the optional CA certificate field during setup.
  • Cannot reach Jira — Ensure the base URL is correct and reachable over HTTPS. If your Jira is behind a firewall, make sure ZeroPath’s egress IPs are added to your network allowlist (shown in the connection dialog). If your Jira is on a fully private network, contact ZeroPath support about self-hosted deployment options.