SecOps
Jira tickets for fixes
SecOps files one Jira ticket for a fix, rather than one for every finding it addresses. This guide explains routing, the queued state and how to verify that the issue was actually remediated.
Configure the two Jira connections
In Settings → Jira tickets, connect:
- Jira: reads projects and the status of tickets SecOps filed.
- Jira for sending: creates and updates the tickets.
Sending uses an Atlassian Cloud site. The sending account needs Browse projects, Create issues and Add comments in the relevant projects. The same account and token can support both connections if it has the necessary access. Set up Jira sync is offered when Jira is connected but the app is not reading it yet.
Decide where work goes
Map each team to a Jira project, and select a project for Any other team where appropriate.
| Fix ownership | Routing |
|---|---|
| Exactly one owner team | That team's mapped project, or the fallback |
| Several owner teams | The fallback project |
| No owner team | The fallback project |
Without a usable destination, a ticket cannot be routed. Check shared fixes and unowned work rather than assuming the team filter changes their ownership.
File a ticket
Open Tickets, review the fix's findings, worst severity, earliest deadline and teams, then choose File ticket. A ticket request covers the fix's identity, not just the filtered page of findings currently visible.
| State | Meaning |
|---|---|
| Not filed | No ticket request is shown for this fix |
| On its way to Jira | The request is saved and queued for the sync |
| Jira key and status | The app has read back the created ticket |
The scheduled Jira sync starts daily at 02:30 UTC. Queueing is not immediate creation, and a failed sync can delay it. Check the connection and pipeline result if it stays queued.
Why is there only one ticket?
A fix identity combines workstream, scope and title. Repeated filing uses that identity instead of creating a ticket for every finding or every filtered view. Team assignment is not part of the identity, so a shared fix is still one piece of work.
Read Remediation for grouping rules before assuming two similarly named fixes should share a ticket.
A closed ticket is not a verified fix
Jira status describes the work item. The source scanner or findings table determines whether the vulnerability is still open. After deploying a change, check both the source result and the next SecOps model run.
Access reviews can record ticket references, but those records do not automatically file Jira issues. Access attention items do not use this vulnerability fix-ticket flow.