Skip to main content
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

​
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.
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.

​
OAuth scopes requested

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:
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.