Release: Merge release into master from: release/2.47.4

[github-actions]

Release triggered by rossops

[dryrunsecurity]

This pull request contains multiple non-blocking findings related to potential race conditions in log entry deletion and a potential information disclosure risk in debugging documentation, with all issues currently marked as "passing" and not requiring immediate blocking of the merge.

Potential Race Condition in Log Entry Deletion in dojo/utils.py

Vulnerability	Potential Race Condition in Log Entry Deletion
Description	Non-atomic operations in log entry deletion could lead to inconsistent state in highly concurrent environments. The current implementation may not guarantee complete data integrity during object deletion.

django-DefectDojo/dojo/utils.py

Lines 18 to 32 in 875aed9

	import hyperlink
	import vobject
	from asteval import Interpreter
	from auditlog.models import LogEntry
	from cryptography.hazmat.backends import default_backend
	from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
	from dateutil.parser import parse
	from dateutil.relativedelta import MO, SU, relativedelta
	from django.conf import settings
	from django.contrib import messages
	from django.contrib.auth.signals import user_logged_in, user_logged_out, user_login_failed
	from django.contrib.contenttypes.models import ContentType
	from django.core.exceptions import ValidationError
	from django.core.paginator import Paginator
	from django.db.models import Case, Count, IntegerField, Q, Sum, Value, When

Potential Race Condition in Log Entry Deletion in dojo/utils.py

Vulnerability	Potential Race Condition in Log Entry Deletion
Description	Non-atomic operations in log entry deletion could lead to inconsistent state in highly concurrent environments. The current implementation may not guarantee complete data integrity during object deletion.

django-DefectDojo/dojo/utils.py

Lines 2335 to 2349 in 875aed9

	logger.debug("ASYNC_DELETE: object has already been deleted elsewhere. Skipping")
	# The id must be None
	# The object has already been deleted elsewhere
	except LogEntry.MultipleObjectsReturned:
	# Delete the log entrys first, then delete
	LogEntry.objects.filter(
	content_type=ContentType.objects.get_for_model(obj.__class__),
	object_pk=str(obj.pk),
	action=LogEntry.Action.DELETE,
	).delete()
	# Now delete the object again
	obj.delete()
	@dojo_async_task
	@app.task

Information Disclosure via Debugging in docs/content/en/share_your_findings/troubleshooting_jira.md

Vulnerability	Information Disclosure via Debugging
Description	Detailed debugging instructions in documentation could expose sensitive system information if logging is enabled at DEBUG level. Administrators should be cautious about enabling verbose logging in production environments.

django-DefectDojo/docs/content/en/share_your_findings/troubleshooting_jira.md

Lines 97 to 146 in 875aed9

	4. Type in 'Epic Name'
	5. Add Epic Name as a field to this particular screen by following Jira's instructions.
	
	## Jira and DefectDojo are out of sync
	Sometimes Jira is down, or DefectDojo is down, or there was bug in a webhook. In this case, Jira can become out of sync with DefectDojo. If this is the case for lots of issues, manual reconciliation might not be feasible. For this scenario there is the management command 'jira_status_reconciliation'.
	As this command requires access to the backend, it is not available to Cloud users of DefectDojo Pro; instead, please contact our Support team for assistance with this issue.
	{{< highlight bash >}}
	usage: manage.py jira_status_reconciliation [-h] [--mode MODE] [--product PRODUCT] [--engagement ENGAGEMENT] [--dryrun] [--version] [-v {0,1,2,3}]
	Reconcile finding status with JIRA issue status, stdout will contain semicolon seperated CSV results.
	Risk Accepted findings are skipped. Findings created before 1.14.0 are skipped.
	optional arguments:
	-h, --help show this help message and exit
	--mode MODE - reconcile: (default)reconcile any differences in status between Defect Dojo and JIRA, will look at the latest status change
	timestamp in both systems to determine which one is the correct status
	- push_status_to_jira: update JIRA status for all JIRA issues
	connected to a Defect Dojo finding (will not push summary/description, only status)
	- import_status_from_jira: update Defect Dojo
	finding status from JIRA
	--product PRODUCT Only process findings in this product (name)
	--engagement ENGAGEMENT
	Only process findings in this product (name)
	--dryrun Only print actions to be performed, but make no modifications.
	-v {0,1,2,3}, --verbosity {0,1,2,3}
	Verbosity level; 0=minimal output, 1=normal output, 2=verbose output, 3=very verbose output
	{{< /highlight >}}
	This can be executed from the uwsgi docker container using:
	{{< highlight bash >}}
	$ docker compose exec uwsgi /bin/bash -c 'python manage.py jira_status_reconciliation'
	{{< /highlight >}}
	DEBUG output can be obtains via `-v 3`, but only after increasing the logging to DEBUG level in your settings.dist.py or local_settings.py file
	{{< highlight bash >}}
	$ docker compose exec uwsgi /bin/bash -c 'python manage.py jira_status_reconciliation -v 3'
	{{< /highlight >}}
	At the end of the command a semicolon seperated CSV summary will be printed. This can be captured by redirecting stdout to a file:
	{{< highlight bash >}}
	$ docker compose exec uwsgi /bin/bash -c 'python manage.py jira_status_reconciliation > jira_reconciliation.csv'
	{{< /highlight >}}

---

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