Jira Done means Awaiting Verification in Fendix. Only sufficient, trusted scan evidence can produce Verified Resolved.
1. Keep the system boundary clear
- Fendix owns the security deadline, verification state, SLA breach state, accepted-risk periods, reopen decisions, and remediation metrics.
- Jira owns assignees, teams, sprints, backlog state, comments, and daily engineering workflow. Ownership displayed in Fendix is synchronized and read-only.
- Closing or resolving a Jira issue never proves that a vulnerability is absent. It creates a verification boundary in Fendix.
2. Publish policy and enroll findings
- An organization administrator publishes an immutable remediation-policy revision. Rules may use severity, confidence, and asset criticality; an explicit default covers missing context.
- Start an enrollment for an environment. Fendix snapshots eligible tracked findings and pins each new case to the policy revision used to calculate its original deadline.
- Publishing a later policy revision does not silently recalculate existing deadlines. Enrollment reports held records separately instead of guessing their identity or risk context.
3. Connect the Jira execution layer
- Connect Jira in Settings, then publish a project-specific mapping from immutable Jira status IDs to done or not-done semantics. Customer status names are never guessed.
- Create a Jira issue from a governed case. Fendix stores a durable creation intent before sending the request and does not send an assignee, sprint, backlog placement, or working comments.
- A trusted Jira completion event moves Open or Reopened to Awaiting Verification. A later mapped not-done event returns the case to its previous unresolved state.
4. Verify the actual fix
- Completion-triggered verification must observe the intended fix context after the relevant Jira Done boundary. Full-scan evidence is bound to the same case, episode, target, source, and deployment context.
- Failed, skipped, stale, cancelled, or insufficiently covered scans cannot prove remediation. A negative result is accepted only from enabled analyzer and check versions with trusted authorization, coverage, deployment, and clock proofs.
- A valid positive detection remains authoritative evidence that the vulnerability exists even when its scan attempt is too stale to trigger an unrelated workflow transition. Recurrence reopens the case without resetting its original deadline.
5. Review risk acceptance and false positives independently
- A member supplies a reason and, for risk acceptance, an expiry no more than 30 days away. An independent administrator must approve or confirm it; requesters cannot review their own request.
- Risk acceptance affects SLA accounting according to the pinned policy. Revocation or verified closure ends the active period. If a closure is later contested, Fendix also corrects the acceptance termination created by that closure.
- A false-positive decision excludes time from remediation reporting but does not manufacture a Verified Resolved state. It can be reversed when new evidence invalidates the decision.
6. Recover Jira synchronization safely
- Queued operations are retried with the same durable identity. If a network failure makes the outcome ambiguous, Fendix enters reconciliation and reads Jira before deciding whether another mutation is safe.
- Duplicate webhooks and delivery retries are idempotent. Mapping gaps, authentication failures, ambiguous outcomes, and recovery status stay visible on the case.
- Use Retry safely only for queued commands or operations requiring reconciliation. A rejected creation needs its configuration corrected and a new creation request.
7. Read the metrics separately
- Time to Jira completion measures engineering workflow; time awaiting verification measures the evidence delay after Jira completion.
- Time to verified resolution ends only at an accepted verification claim. SLA breach duration and accepted-risk duration are calculated from retained case episodes and corrected intervals.
- Reopen rate reports recurrence after a valid resolution. These metrics are separate because combining them would hide whether delay came from engineering, verification, risk acceptance, or recurrence.