🎉 Advance reimport to update fix_available field #12633

[manuel-sommer]

#12633 (comment)

TODO: Documentation

[manuel-sommer]

@valentijnscholten is this the right direction for updating fix_available in reimport?

[valentijnscholten]

Yes

[manuel-sommer]

Shall I target this against bugfix, or do we want a longer testphase and keep it against dev?

[dryrunsecurity]

🔴 Risk threshold exceeded.

This pull request contains a potential data integrity issue in the default reimporter where an imported scan report can directly update the fix_available status of a security finding without server-side validation, which could lead to inaccurate security reporting. Additionally, sensitive edits were detected in the default_reimporter.py file.

🔴 Configured Codepaths Edit in dojo/importers/default_reimporter.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

Data Integrity Issue in Finding Status in dojo/importers/default_reimporter.py

Vulnerability

Data Integrity Issue in Finding Status

Description

The fix_available status of an existing security finding is updated directly from an imported scan report via unsaved_finding.fix_available. There is no apparent server-side validation or verification of this flag. This allows a user-controlled input (the imported scan file) to directly influence a critical status field of a security finding. An attacker or a misconfigured scanner could falsely mark a finding as having a fix available, leading to inaccurate security posture reporting and potentially delaying the remediation of actual vulnerabilities.

django-DefectDojo/dojo/importers/default_reimporter.py

Lines 538 to 546 in 7b12ecf

	# First check that the existing finding is definitely not mitigated
	if not (existing_finding.mitigated and existing_finding.is_mitigated):
	logger.debug("Reimported item matches a finding that is currently open.")
	if unsaved_finding.fix_available:
	logger.debug("Reimported finding has a fix available now.")
	existing_finding.fix_available = True
	if unsaved_finding.is_mitigated:
	logger.debug("Reimported mitigated item matches a finding that is currently open, closing.")
	# TODO: Implement a date comparison for opened defectdojo findings before closing them by reimporting,

We've notified @mtesauro.

---

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

[valentijnscholten]

The main reason fields are not updated during reimport is that there's a risk it overwrites fields that were changed by the user. At least that's what I think the reason is. And this could be an issue here are the user may have set the fix_available field to None or False explicity. On the other hand we want to make that if a fix has become available we update the finding. What are your thoughts on this @Maffooch @mtesauro

[manuel-sommer]

I mean that is what is requested also in the linked issue explicitly.

[valentijnscholten]

We've discussed this and since this is sort of a "status" field or "meta" field it's OK to let reimport update it. Two remarks:

• I think we would just always need to update it, so also the case where it goes from True to False (or to None)
• I think it would have to be updated for any existing finding, so all branches of process_matched_finding.

[Maffooch]

We've discussed this and since this is sort of a "status" field or "meta" field it's OK to let reimport update it. Two remarks:

• I think we would just always need to update it, so also the case where it goes from True to False (or to None)
• I think it would have to be updated for any existing finding, so all branches of process_matched_finding.

I agree with this approach