Reimport: Special statuses should be respected from reports

[Maffooch]

Replacement of #12249

When performing a reimport, the status of a finding from the report that is either false positive, out of scope, or risk accepted is being discarded. This is due to a flaw in the way findings are calculated for the close_old_findings function.

Let's say we have a finding in the database that is active. In the next reimport, the same finding is being reported form the tool as false positive. Reimport will do the following:

1. Store the list of original findings
2. Parse the findings
3. Find a match between this new false positive finding, and the existing active finding
4. Set the active finding to false positive, and save the finding to the database
5. Determine the findings to be closed by subtracting the findings from the report from the original list of findings from step 1.
   • This is just the original active finding (though the record is stale since it was updated in step 4.)
6. Close the active finding by setting the mitigated status
7. Find out that the false positive status was discarded

This situation is caused from attempting to close a stale record, that may or may not already be closed, and therefore overwrite any other statuses. The solution here is simple: fetch the latest status on the finding before deciding if it needs to be closed.

[sc-10908]

[dryrunsecurity]

🟡 Please give this pull request extra attention during review.

This pull request reveals a potential mass assignment vulnerability in the Checkmarx One parser that could allow unauthorized attribute assignment, along with additional findings related to race conditions and SQL injection risks in test JSON files that may require further security review.

⚠️ Potential Mass Assignment Vulnerability in dojo/tools/checkmarx_one/parser.py

Vulnerability	Potential Mass Assignment Vulnerability
Description	The code uses the **instance_details syntax to dynamically assign multiple attributes to the Finding model, which could potentially introduce a Mass Assignment vulnerability if instance_details contains user-controlled or unvalidated data

django-DefectDojo/dojo/tools/checkmarx_one/parser.py

Lines 175 to 189 in 796ee74

	date = self._parse_date(instance.get("firstFoundDate"))
	else:
	date = self._parse_date(instance.get("foundDate"))
	instance_details = self.determine_state(instance)
	instance_details.update(base_finding_details)
	# Create the finding object
	finding = Finding(
	severity=instance.get("severity").title(),
	date=date,
	file_path=instance.get("destinationFileName"),
	line=instance.get("destinationLine"),
	**instance_details,
	)
	# Add some details to the description
	if node_snippet := get_node_snippet(instance.get("nodes", [])):

💭 Unconfirmed Findings (2)

Vulnerability	Race Condition in default_reimporter.py
Description	Potential data inconsistency during concurrent finding status modifications in the default_reimporter.py file. Mitigation added by using refresh_from_db() to prevent race conditions when updating finding statuses.

Vulnerability	SQL Injection Vulnerabilities in Test JSON Files
Description	Multiple Java source files in test JSON scans contain potential SQL injection risks. Specifically identified in SqlInjectionLesson3.java and SqlInjectionLesson6a.java. Direct user input is embedded in SQL queries without proper sanitization, potentially allowing attackers to inject malicious SQL syntax. Classified under CWE-89 (Improper Neutralization of Special Elements in SQL Command).

---

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

[mtesauro]

Approved