Jira and ticketing

Prioritised findings become Jira tickets, and ticket status flows back. The sync is deliberately conservative in one direction: Sinterly will not silently change what your findings say happened.

Connecting

Integrations, then Ticketing, then Jira, then Connect. You provide your site URL, account email, API token, project key, and optionally an issue type ID if your project uses a custom type.

The connection is tested against your Jira before it can be saved. Once saved, the credential is encrypted and never displayed again.

Outbound: findings become tickets

Scored, open findings without a ticket are created in your project. Each ticket is structured for the fact that several different people will read it:

Inbound: status changes need a human

When a ticket's status changes in Jira, Sinterly does not update the finding automatically. The change enters a confirmation queue where an AppSec Lead approves or rejects it.

This is intentional. A closed ticket does not always mean a fixed vulnerability. Tickets get closed as duplicates, closed by mistake, closed because a sprint ended. Somebody accountable confirms the connection between "ticket done" and "vulnerability gone", and the confirmation is audited.

A daily reconciliation pass catches anything a webhook missed, so a dropped event does not leave your two systems disagreeing indefinitely.

Reviewing the queue

Open Jira queue as an AppSec Lead. Each pending change shows the finding, the ticket, and the proposed status. Approving applies it and records who approved. Rejecting requires a reason.

Other ticketing systems

Asana and Azure DevOps are on the roadmap and appear in the Integrations page with a Register interest button. Registering interest genuinely determines what gets built next. See Integrations.