fix: handle missing status_finding_non_special prefetch in reimporter

[seantechco]

Summary

• Fixes AttributeError: 'Finding' object has no attribute 'status_finding_non_special' during reimport-scan
• Adds EndpointManager.get_non_special_endpoint_statuses() helper that uses the prefetched attribute when available and falls back to an equivalent DB query otherwise
• Applies the helper at both access sites: default_reimporter.py and endpoint_manager.py

Bug

During reimport, when a scan report contains duplicate findings (same hash_code/unique_id), the first occurrence creates a new finding via process_finding_that_was_not_matched() and adds it to the candidate dictionaries via add_new_finding_to_candidates(). When a subsequent finding in the same batch matches against this newly-created finding, process_matched_mitigated_finding() or update_endpoint_status() accesses existing_finding.status_finding_non_special, which raises AttributeError.

Root Cause

The status_finding_non_special attribute is a Prefetch with to_attr set up in build_candidate_scope_queryset() (deduplication.py:306-316). This prefetch is only applied to findings loaded from the database through that queryset. Findings created during the same reimport batch (via save_no_options() in process_finding_that_was_not_matched()) and added to candidate dictionaries never pass through that queryset, so they lack the prefetched attribute.

Fix

Added EndpointManager.get_non_special_endpoint_statuses() as a @staticmethod that:

1. Returns finding.status_finding_non_special if the prefetch attribute exists (hasattr check)
2. Falls back to finding.status_finding.exclude(Q(false_positive=True) | Q(out_of_scope=True) | Q(risk_accepted=True)).select_related("endpoint") — the exact same filter logic as the Prefetch definition

Updated both call sites to use this helper:

• dojo/importers/default_reimporter.py line 768 (process_matched_mitigated_finding)
• dojo/importers/endpoint_manager.py line 162 (update_endpoint_status)

Test plan

• Reimport a scan report that contains findings matching existing mitigated findings in the test
• Reimport a scan report with duplicate findings (same hash_code) where the first creates a new finding and the second matches against it
• Verify no AttributeError on status_finding_non_special
• Verify endpoint statuses are correctly reactivated/mitigated during reimport

🤖 Generated with Claude Code

[dryrunsecurity]

This pull request modifies sensitive files (dojo/importers/default_reimporter.py and dojo/importers/endpoint_manager.py), triggering the configured-codepaths analyzer which flags these edits as errors; review carefully or update .dryrunsecurity.yaml if these changes are expected and authors are allowed.

🔴 Configured Codepaths Edit in dojo/importers/default_reimporter.py (drs_dc5c1792)

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/importers/endpoint_manager.py (drs_77f1ef31)

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.

[valentijnscholten]

@seantechco Thanks for the report. Interesting case which is not covered by tests yet. With which parser did you see this problem? And if you happen to have a anonimized sample report to reproduce it with that woudl be great.
I am having trouble finding a good parser to build a test case with :-)