refactor: decouple Jira integration into dojo/jira package

[Maffooch]

Description

Extracts all Jira integration code into a dedicated dojo/jira package and introduces dojo/jira/services.py as the single entry point for the rest of the application. The goal is to remove direct coupling between core models/forms/views/importers and Jira internals so the Jira module can evolve without touching consumers across the codebase.

What changed:

• Renamed dojo/jira_link/ → dojo/jira/ and added models.py, forms.py, and api/{serializers,views}.py to hold the Jira-specific pieces previously embedded in dojo/models.py, dojo/forms.py, and dojo/api_v2/.
• New dojo/jira/services.py (service-layer module matching the services.py convention used elsewhere, e.g. dojo/engagement/services.py) exposing the public Jira surface consumed by non-Jira modules. Each wrapper is a one-line delegation to dojo.jira.helper, lazy-imported inside the module to break the import cycle between dojo.forms / dojo.models / dojo.utils and dojo.jira.helper. Real Jira errors propagate to callers instead of being swallowed.
• Direct Jira imports removed from: dojo/models.py, dojo/forms.py, dojo/api_v2/{serializers,views}.py, dojo/finding/{helper,views}.py, dojo/finding_group/views.py, dojo/engagement/{services,views}.py, dojo/product/views.py, dojo/test/views.py, dojo/risk_acceptance/helper.py, dojo/templatetags/display_tags.py, dojo/importers/*, dojo/tasks.py, and dojo/utils.py (SLA notifications). Management commands (jira_async_updates, jira_refactor_data_migration, jira_status_reconciliation, push_to_jira_update) updated to import from the new package.
• .dryrunsecurity.yaml sensitive-codepaths glob updated to track dojo/jira/**.

No behavior change is intended — this is a code-move / import-boundary cleanup. No DB schema changes and no new settings.

[dryrunsecurity]

This pull request may introduce mass-assignment risks: it unpacks request.data into dojo_dispatch_task(...) allowing clients to set arbitrary task kwargs, and it forwards entire HttpRequest objects into jira_services.process_project_form(...) (which only delegates to a helper), potentially enabling uncontrolled request data to reach model saves or forms unless the downstream helper explicitly allowlists/validates fields.

🔴 Potential Mass Assignment Vulnerability in dojo/api_v2/views.py (drs_08ca8880)

Vulnerability

Potential Mass Assignment Vulnerability

Description

The code calls dojo_dispatch_task(task, engagement.id, **request.data), expanding request.data into keyword args and forwarding them into a background task without explicit allowlisting or validation at the call site. This may allow a client to set arbitrary parameters that the task (or downstream code) accepts, matching the pattern for mass-assignment when request data is unpacked into function arguments.

django-DefectDojo/dojo/api_v2/views.py

Lines 719 to 722 in e70e26a

	dojo_dispatch_task(task, engagement.id, **request.data)
	response = Response(
	{"info": "Jira Epic update query sent"},
	status=status.HTTP_200_OK,

🟠 Potential Mass Assignment Vulnerability in dojo/product/views.py (drs_3d4598e7)

Vulnerability

Potential Mass Assignment Vulnerability

Description

The code forwards the entire HttpRequest object into jira_services.process_project_form(request, ...). The new dojo.jira.services module is a thin wrapper that delegates to dojo.jira.helper.process_jira_project_form; the wrapper passes the same request object to the helper. Because process_project_form receives the full request, if the underlying helper applies request.POST (or request.data) directly to model.save() or ModelForm without explicit allowlisting, that could permit mass assignment. Inspecting the patch shows the new services wrapper does not itself perform field filtering or validation — it simply delegates to the helper — so the only mitigation would be inside dojo.jira.helper.process_jira_project_form (not included in the patch). Without proof that the helper uses a Django Form/Serializer or explicit allowlist, this is potentially dangerous.

django-DefectDojo/dojo/product/views.py

Lines 1043 to 1046 in e70e26a

	success, jform = jira_services.process_project_form(request, instance=jira_project, product=product)
	error = not success
	if get_system_setting("enable_github") and github_inst:

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.

[mtesauro]

Approved

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.