feat: Add pghistory tracking for tag fields

[valentijnscholten]

Summary

This PR adds pghistory tracking for tag changes on all tagged models in DefectDojo. Previously, tag additions and removals were not tracked in the audit history.

Changes

Tag Tracking via Through Models

• Added pghistory tracking for tag through models using dynamic proxy classes (same pattern as FindingReviewers)
• Tracks both tags and inherited_tags fields for all applicable models:
  • Finding (tags, inherited_tags)
  • Product (tags)
  • Engagement (tags, inherited_tags)
  • Test (tags, inherited_tags)
  • Endpoint (tags, inherited_tags)
  • Finding_Template (tags)
  • App_Analysis (tags)
  • Objects_Product (tags)

History View Improvements

• Changed DojoEvents.objects.tracks(obj) to DojoEvents.objects.references(obj) to include related through model events (tags, reviewers) in the history view
• Improved object display in history view:
  • Finding updates now show the actual title instead of "Object ID: 4313"
  • Tag events show "Tag 'tagname' on Finding" instead of "Tag ID 4 on Finding"
  • Reviewer events show "Reviewer 'User Name' on Finding Bump sqlalchemy from 1.4.8 to 1.4.9 #4313"
• Made Object and Object ID columns clickable - users can now click to navigate directly to the object

Database Migrations

• 0256_pghistory_for_tags_models.py: Creates proxy models and event tables/triggers for all 12 tag through models
• 0257_pghistory_tags_backfill.py: Data migration to backfill existing tag data into the new event tables

Backfill Commands Updated

• Updated pghistory_backfill.py and pghistory_backfill_simple.py to include the new tag through models

UI improvements

• Action history now also shows linked objects like reviewers, tags, ...
• Object column now shows title of findings, tags, reviewers.
• Object and Object ID column now have clickable links.

The Pro does not break Pro.

[dryrunsecurity]

🟡 Please give this pull request extra attention during review.

This pull request introduces a template that renders h.object_url directly into an href without validating or normalizing the URL, which could allow an attacker who can influence stored snapshots or object URLs to inject a javascript: or other dangerous scheme and cause XSS or unsafe navigation; h.pgh_obj_id is also rendered unvalidated in link text. Review and sanitize/validate object_url (ensure only safe schemes or use framework escaping/URL builders) before rendering to mitigate the risk.

🟡 Potential Cross-Site Scripting in dojo/templates/dojo/action_history.html

Vulnerability

Potential Cross-Site Scripting

Description

The template renders h.object_url directly into an href attribute without any URL validation or framework-level escaping being explicitly enforced. process_events_for_display constructs object_url values and sets them to instance.get_absolute_url() when an instance is found, but for many events it sets object_url = None and otherwise reconstructs object_str only; there is no evidence in the patch that object_url is validated or normalized to a safe scheme. The template branch uses {% if h.object_url and h.pgh_obj_id %} ... which will place whatever string is in h.object_url into the href attribute unvalidated. An attacker able to influence pghistory snapshots (for example via crafted pgh_data entries, or if get_absolute_url implementations or stored snapshots can be influenced) could inject a javascript: URL or other dangerous value leading to XSS or unsafe navigation. Similarly, rendering h.pgh_obj_id directly into link text is lower risk but could expose unexpected content if it isn't strictly numeric; the primary risk is the unvalidated href.

django-DefectDojo/dojo/templates/dojo/action_history.html

Lines 78 to 80 in 230c07a

	{% if h.object_url and h.pgh_obj_id %}
	<a href="{{ h.object_url }}">{{ h.pgh_obj_id }}</a>
	{% else %}

---

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