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:

• A business impact section in plain language, for whoever prioritises the work.
• The technical detail, affected location and reproduction guidance, for the engineer who fixes it.
• An effort estimate split into code time and process time, for sprint planning.

One finding, or all of them

There are two ways a ticket gets created, and the difference matters.

• One finding, on demand. Open a finding and use Create Jira ticket. Only that finding is ticketed. This is the usual case: you have read the evidence on a single finding and you want that one in front of a developer today.
• Everything, at the end of a run. When a pipeline run finishes, every open scored finding that does not already have a ticket gets one. That is the right behaviour for a team working the whole backlog, and the wrong one if you wanted a single ticket, so reach for the button rather than a run when you mean one.

Both paths build the same ticket, and both skip a finding that already has one, so nothing is ever ticketed twice.

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.