Jira Linked Issue Automatically Reopening

[FuzzyGophers]

I have created an engagement and uploaded a Trivy scan (trivy config) and a Coverity scan (to compare scanners).

Steps to reproduce
Steps to reproduce the behavior:

1. Create Engagement

2. Upload Trivy or Coverity scan via "Import Scan Results" inside the engagement

3. Edit a defect
   3a. Set to "Active" and "Verified"
   3b. Set "Push to Jira" (We are not pushing all findings for the engagement automatically)

4. Jira bug (and epic) are created as expected

5. Close the defect in Dojo with comment

6. Jira bug is closed as expected with comment and Dojo sets the defect to "Inactive, Mitigated"

However, something is causing the defect in Dojo to reopen and go back to "Active, Verified".

There are no other engagements within the Product. So, I don't think it is the dedupe process.

This same workflow on a non-Jira linked defect works as expected. The defect remains as "Inactive, Mitigated".

I looked for Jira related events in the logs. The following event may be helpful:

"Unrecognized JIRA webhook event received: issuelink_created"

My current thought is that maybe Dojo is reopening the bug as the callback from Jira looks to be unsuccessful here?

Any suggestions where to look? Happy to provide more details... just unsure what else to look for.

Expected behavior
The defect in Dojo should remain in the "Inactive, Mitigated" state.

Deployment method (select with an X)

• [ X ] Kubernetes

Environment information

• Operating System: [e.g. Ubuntu 18.04]
• DefectDojo version (see footer) or commit message: [use git show -s --format="[%ci] %h: %s [%d]"]: 2.31.1

Additional Context

Maybe this is related to #9512, API changes, or my version of Jira?

[FuzzyGophers]

I was able to investigate this further. I think I have found the issue.

I am seeing the following in my logs:

---

[20/Feb/2024 17:22:09] DEBUG [dojo.jira_link.helper:1565] Re-opening related finding of WRSDSEC-31

This is logged from the following code:

django-DefectDojo/dojo/jira_link/helper.py

Line 1567 in a2f7c97

logger.debug("Re-opening related finding of {}".format(jira_issue.jira_key))

---

However, I should be hitting

django-DefectDojo/dojo/jira_link/helper.py

Line 1555 in a2f7c97

logger.debug("Marking related finding of {} as mitigated (default)".format(jira_issue.jira_key))

as I have marked the finding as closed (which works in non-Jira linked issues)

Backtracking, we will only enter in this conditional if resolved is true:

django-DefectDojo/dojo/jira_link/helper.py

Line 1527 in a2f7c97

if resolved:

which requires resolution_id to have some value:

django-DefectDojo/dojo/jira_link/helper.py

Line 1524 in a2f7c97

resolved = resolution_id is not None

This leads to

django-DefectDojo/dojo/jira_link/views.py

Line 107 in a2f7c97

jira_helper.process_resolution_from_jira(finding, resolution_id, resolution_name, assignee_name, jira_now, jissue)

which passes resolution_id

resolution_id is set here from the resolution array:

django-DefectDojo/dojo/jira_link/views.py

Line 101 in a2f7c97

resolution_id = resolution['id'] if resolution else None

resolution is defined here:

django-DefectDojo/dojo/jira_link/views.py

Line 85 in a2f7c97

resolution = parsed['issue']['fields']['resolution']

resolution does not include ['id'] in the assignment hence we will never enter the logic starting at

django-DefectDojo/dojo/jira_link/helper.py

Line 1524 in a2f7c97

resolved = resolution_id is not None

@manuel-sommer and @Maffooch would you please review my logic here?

---

If I am correct, I think is a simple patch of the following:

django-DefectDojo/dojo/jira_link/views.py

Line 85 in a2f7c97

resolution = parsed['issue']['fields']['resolution']

resolution = parsed['id']['issue']['fields']['resolution']

[FuzzyGophers]

Ah, disregard.

resolution = parsed['issue']['fields']['resolution'] is sufficient with the ['resolution'] being passed.

Will continue to investigate on Jira side here.

[FuzzyGophers]

I have resolved this issue.