Work goes outTicketing
Jira
Routes findings into the Jira project the owning team already works in, keeps the ticket and the finding in step in both directions, and closes neither until a rescan proves the fix.
What the connector does
- One ticket per finding, in the project and issue type your routing rules choose
- Status changes flow both ways — a transition in Jira moves the finding, and the reverse
- Deduplicated: a finding that already has a ticket never gets a second one
- Delivery is queued and retried, so a Jira outage delays a ticket rather than losing it
Credential required
A Jira account address and API token with permission to create and transition issues in the projects you name.
What this connector is for
Security work that lives in a security tool is work engineers never see. The remediation loop only closes if the ticket appears where the team already looks, in the sprint they are already planning — which means the platform has to write into Jira rather than asking anybody to visit a second queue.
What is delivered
The finding, with its evidence, its affected asset, its priority and its deadline, as an issue in the project your routing rules select. Priority maps to your own scheme, and the SLA due date becomes a due date the team can see. Nothing about the finding is duplicated into the description that would go stale — the ticket links back for the detail that changes.
What comes back
Transitions. When somebody moves the ticket to In Progress, the finding moves with it; when the ticket is resolved, the finding enters verification rather than closing. That last distinction is the whole point: a resolved ticket is a claim, and the platform closes the finding only when a rescan finds the problem gone.
What you have to grant
An API token for an account that can create and transition issues in the projects you name. Credentials are stored encrypted, and the token is never returned by any endpoint after it is saved.