> ## Documentation Index
> Fetch the complete documentation index at: https://docs.app.strix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Jira Integration

> Connect Strix to Jira Cloud to export vulnerabilities as issues and keep statuses in sync

export const ScarfPixel = () => <img referrerPolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=831669b6-b4bd-42cb-8832-2122c03e1d5f" alt="" width="1" height="1" style={{
  position: "absolute",
  width: 0,
  height: 0,
  opacity: 0,
  pointerEvents: "none"
}} />;

<ScarfPixel />

Strix integrates natively with Jira Cloud so vulnerabilities found by scans and PR reviews can be exported as Jira issues and kept in sync in both directions. This page covers setup, the OAuth scopes requested, what data is exchanged, and how to disconnect.

## Overview

|                       |                                                                                        |
| --------------------- | -------------------------------------------------------------------------------------- |
| Integration type      | Native Atlassian OAuth 2.0 (3LO) app — no third-party middleware in the data path      |
| Direction             | Bidirectional: Strix creates/updates issues; Jira status changes sync back via webhook |
| Who can connect       | Strix organization **admins** only                                                     |
| Jira products touched | Jira Cloud (via the `api.atlassian.com` gateway, scoped to one site/cloud ID)          |
| Hosting               | Jira Cloud only (Jira Server / Data Center is not supported)                           |

## Setup

1. In Strix, go to **Settings → Integrations** and click **Connect** on the Jira card. You must be an organization admin, and your plan must include ticketing integrations.
2. Strix opens the standard Atlassian consent screen (`auth.atlassian.com`). Sign in with a Jira account that has permission to browse projects and create issues in the projects you want to export to, and approve the requested scopes.
3. Atlassian redirects back to `https://app.strix.ai/api/integrations/jira/callback`. Strix exchanges the authorization code for tokens, records the Jira site (cloud ID and site URL), and registers a webhook for inbound status sync.
4. Back in Strix, pick a **default project** (and optionally a default issue type) as the export destination, and optionally enable **auto-sync** with a minimum severity so new findings are exported automatically.

<Note>
  If the authorizing Atlassian account has access to multiple Jira sites, Strix connects the first accessible site. Use an account scoped to the intended site if you have several.
</Note>

## OAuth scopes requested

| Scope                 | Why Strix needs it                                                     |
| --------------------- | ---------------------------------------------------------------------- |
| `read:jira-work`      | List projects and issue types; read issue status when syncing          |
| `write:jira-work`     | Create issues, post status comments, transition issues                 |
| `read:jira-user`      | Required by Atlassian for issue operations that resolve users          |
| `manage:jira-webhook` | Register/refresh the webhook used for inbound status sync              |
| `offline_access`      | Receive a refresh token so the connection survives access-token expiry |

Access tokens are short-lived and refreshed automatically using the rotating refresh token. All API calls go through `https://api.atlassian.com/ex/jira/<cloudId>/rest/api/3`, scoped to the single connected site.

## What data flows where

**Strix → Jira** (when a vulnerability is exported, manually or via auto-sync):

* Issue summary: the vulnerability title (truncated to Jira's limit).
* Issue description: severity, CVSS/CVE (when present), target/endpoint or affected file, impact, technical analysis, evidence, suggested fix or remediation steps, proof of concept, and a link back to the issue in Strix.
* Priority mapped from severity, and a due date when an issue is snoozed.
* Status comments (e.g. "marked In Progress by …") when the Strix status changes.

**Jira → Strix** (via webhook on `jira:issue_updated`):

* The issue ID/key, its status category (new / in progress / done), due date, and the display name of the user who made the change. Strix maps the status category back onto the linked vulnerability's status.

Strix does not read existing Jira issues, attachments, comments, or user directories; inbound processing is limited to status/due-date updates for issues Strix itself created.

## Security

* **Admin-gated**: both the connect and callback endpoints require an authenticated Strix org admin; the role is re-checked at the callback so a demoted user cannot complete a pending connection.
* **CSRF-protected OAuth**: the OAuth `state` is HMAC-signed, bound to the initiating organization and user, and expires after 10 minutes.
* **Webhook verification**: Jira dynamic webhooks are not signed by Atlassian, so the callback URL embeds a per-connection random secret that is matched (timing-safe) against the stored value before any payload is processed.
* **Token storage**: access/refresh tokens are stored server-side in Strix's database, scoped to your organization, and never exposed to the browser or other tenants.
* **Revocation on disconnect**: disconnecting the integration deletes the webhook and revokes the Atlassian grant (refresh-token revocation invalidates the whole grant), so no live tokens remain on Atlassian's side.
* **Audit trail**: connecting the integration and settings changes are recorded in the Strix audit log.

## Disconnecting

An org admin can disconnect Jira at any time from **Settings → Integrations**, or via the API:

```bash theme={null}
curl -X DELETE "https://app.strix.ai/api/v1/integrations/jira" \
  -H "Authorization: Bearer <YOUR_API_TOKEN>"
```

**Required scope:** `integrations:write`

Disconnecting removes the stored tokens, deletes the Jira webhook, and revokes the OAuth grant. Issues already created in Jira are not deleted.