Skip to content
GoSentrix

Guide

Vulnerability closure in Jira

Jira should record the claim, link to the evidence, and record the review. It should not stand in for them. A ticket can show which outcome is proposed, link the change, verification and deployment records that support it, and show who accepted the closure under which criteria. Moving a ticket to Done records a workflow state. That transition should follow the closure review, not replace it.

What a ticket can and cannot show

Each of these is useful. None of them is, by itself, evidence that the finding was resolved.

SEC-5317 · Security bug

Illustrative

SQL injection in the report export endpoint

  • StatusDoneResolution: Fixed

    What it does not prove: The workflow moved on, and someone claims an outcome. Neither shows the fix was verified or deployed.

  • Linked pull request#1440 · merged

    What it does not prove: A change is linked. Does it address this finding, and did it ship?

  • Fix version2026.11

    What it does not prove: The release it was planned for, not the build that runs where the finding applies.

  • Comment“Verified, looks good.”

    What it does not prove: A statement. What was verified, how, and against what?

  • Deployment recordNot linked

    What it does not prove: Nothing ties the fixed build to the environment where the finding applies.

  • Review recordNone

    What it does not prove: No record of who accepted the closure, or under which criteria.

The ticket reads as closed, but its status, link, fix version and comment are claims and associations. None of them shows the fix was verified, deployed and accepted, and the two records that would are missing. A drawn, generic ticket, not a screenshot of any product.
Jira recordWhat it showsWhat it does not show
Status: DoneThe workflow moved on.That the fix was verified or deployed.
Resolution: FixedThe outcome someone claims.The evidence behind that claim.
Linked pull request or commitA change is associated with the ticket.That the change addresses this finding, or that it shipped.
Fix versionThe release the fix was planned for.Which build actually runs where the finding applies.
Comment: "verified"Someone’s statement.What was verified, how, and against what.

What to require before a closure is reviewed

Finding reference
The scanner or ASPM identifier and link, the affected assets, and the environments where the finding applies.
Proposed outcome
Remediated, not affected, risk accepted or compensating control, held in its own field so it is not confused with the ticket status.
Evidence links
The change that addresses the finding, the verification that covers it (a CI run or rescan), and, where it applies, the deployment record that names the fixed build in the affected environment.
Review record
Who reviewed the closure, when, what they decided, and which version of your closure criteria they applied.
Risk acceptance, when proposed
The risk in plain terms, the basis, the owner, the approver and their authority, a review or expiry date, and the conditions that would reopen it.

The closure evidence checklist explains what each of these should contain for each outcome.

A workflow that keeps status and review apart

Split “the work is done” from “the closure is accepted”.

  1. Open
  2. In remediation
  3. Closure proposed
  4. Closure review
  5. Closed
  • Closure proposed means the team believes the outcome is ready, and the proposed outcome and evidence links are filled in.
  • Closure review is where the designated reviewer checks the evidence against your criteria and accepts the closure, sends it back with a named gap, or reopens it.
  • Jira workflows can usually restrict who performs a transition and require fields before it, depending on your Jira edition and project type. Use that to keep the move to Closed with the designated reviewer.

Illustrative example · not a customer case

SEC-5102: a ticket waiting for closure review

Status
Closure review
Proposed outcome
Remediated
Finding
ASPM-88213 · open redirect in the login service · production
Change
Pull request #2290, merged
Verification
CI run 7781 · test login_redirect_allowlist passed
Deployment
None linked
Review record
Empty

Where this leaves the closure: the ticket says the work is done, and the change and its test support the claim. Nothing links the fixed build to the production login service. Next action: the release manager links the deployment record that names the build. The designated reviewer decides whether to accept the closure once it is linked, or to accept it with the gap recorded.

Names, identifiers and records are made up to show the reasoning.

Where GoSentrix fits

When Jira is your system of record, GoSentrix is designed to treat the ticket as the claim and check it against your code, CI and deployment records. Its Jira integration is a design target, not something to assume is available. GoSentrix does not change Jira workflows or transition tickets.

  • Assesses existing records. For a proposed closure, it checks whether evidence your systems already hold supports the proposed outcome.
  • Names missing support. When evidence is missing, stale or conflicting, it says so, with the next action and who can supply it.
  • Prepares the case. Your designated reviewer inspects it and decides.

GoSentrix assesses evidence that existing systems already produce. It does not run its own tests or scans, block merges or releases, or make the closure decision. The customer’s designated reviewer does.

GoSentrix is available through a paid Finding Closure Assessment. The evidence sources it covers, and any human assistance involved, are agreed before it starts. No controlled demonstration or customer result has been published yet.

Frequently asked questions

Should Done mean the vulnerability is fixed?

Only if your workflow requires the evidence and a review before that transition. Otherwise Done records that the work moved on, not that the fix was verified or deployed. Separating "closure proposed" from "closed" keeps the two apart.

Which fields should a vulnerability ticket have?

A finding reference with scope, a proposed outcome kept separate from status, links to the change, the verification and the deployment record where it applies, a review record, and risk-acceptance fields when that is the outcome.

Does GoSentrix integrate with Jira?

Jira is a design target for GoSentrix, not an integration to assume is available. Which evidence sources a Finding Closure Assessment covers, and how they are accessed, is agreed before it starts.

Related reading

Vulnerability closure evidence checklist

What a reviewer should inspect before closing a finding.

How to prove a vulnerability was fixed

Recorded actions, supporting evidence and unresolved uncertainty.

Jira integration status

What GoSentrix is designed to read from Jira, and its current status.

Finding Closure Assessment

How your team closes serious findings today, and where evidence is missing.

See how your Jira closures hold up.

A Finding Closure Assessment maps how serious findings are closed today, including what your tickets record and what they leave out.

Discuss a Finding Closure AssessmentAbout the assessment