Jira webhook: stop mis-mitigating findings on non-"done" issues

[paulOsinski]

users see findings auto-mitigated immediately after reopening via
either the UI or API. Looking at finding pghistory we see the pattern:

12:32:48 active=True is_mitigated=False source=None ← user reopens
12:32:51 active=False is_mitigated=True source=jira_webhook ← ricochet

mitigated_by is always the system "JIRA" user, set only from one place:
process_resolution_from_jira's "Mitigated by default" branch.

Root cause

Two independent issues compound:

1. Self-inflicted race in update_jira_issue. When DefectDojo
   pushes an update to a linked Jira issue, it does
   issue.update(...) first (priority, description, labels) and then
   push_status_to_jira(...) (the transition). Each API call fires its
   own jira:issue_updated webhook. The first webhook, fired by
   issue.update, sees the pre-transition state - for a reopen, that
   means the issue is still resolved from the previous close. Our
   webhook handler then mitigates the linked finding. The second
   webhook, post-transition, would try to reopen the finding, but for
   grouped findings that reopen is (deliberately) gated behind
   DD_JIRA_WEBHOOK_ALLOW_FINDING_GROUP_REOPEN=False, so the ricochet
   is irreversible.

2. Fragile "resolved" check in the webhook handler. The handler
   treated any non-null resolution as "the Jira issue is closed",
   which also mis-fires for Jira configurations that set a default
   resolution on open issues ("Unresolved"), or workflows whose Reopen
   transition does not clear the resolution field.

Fix

1. Reorder update_jira_issue so the status transition runs before
   other field updates. Webhooks fired during our own sync now see a
   consistent post-transition state.
2. In process_resolution_from_jira, require both resolution AND
   statusCategory.key == "done" before mitigating. Extract the
   statusCategory from the webhook payload in webhook() and pass it
   through.

Tests

Three new tests covering status categories new, indeterminate, and
done, all with a non-null resolution value - regression-locking the
guard against the "open but resolved" state.

Backward compatibility

status_category_key is a keyword-only optional argument on
process_resolution_from_jira. When not supplied, behavior is
identical to before the change.

[dryrunsecurity]

This pull request modifies sensitive files (dojo/jira_link/helper.py and dojo/jira_link/views.py), triggering configured-codepaths alerts for edits to protected paths; review and/or update .dryrunsecurity.yaml to verify allowed authors or confirm the changes. Please ensure these changes are intended and authorized before merging.

🔴 Configured Codepaths Edit in dojo/jira_link/helper.py (drs_fd169a50)

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/jira_link/views.py (drs_87122cb0)

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

We've notified @mtesauro.

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.