🐛 fix close_old_findings through service field in several parsers #14640

[manuel-sommer]

#14640

[manuel-sommer]

@valentijnscholten please take a look here

[dryrunsecurity]

This pull request includes a sensitive edit to the file dojo/db_migrations/0264_clear_service_for_affected_parsers.py that matches configured codepaths rules (see .dryrunsecurity.yaml) and is flagged as an error under the risk threshold; the finding is non-blocking but should be reviewed for allowed authors and path sensitivity.

🔴 Configured Codepaths Edit in dojo/db_migrations/0264_clear_service_for_affected_parsers.py (drs_5c37af90)

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.

[Maffooch]

If a service was supplied to these test types at import time, does that value override the value set by the parser? If so, could this migration potentially erase service fields that are from the user?

[manuel-sommer]

That's a question beyond my knowledge. Maybe @valentijnscholten has an opinion on this.

[valentijnscholten]

The importers overwrite any fields set by the parsers:

django-DefectDojo/dojo/importers/default_importer.py

Lines 216 to 217 in 9d661d7

	if self.service is not None:
	unsaved_finding.service = self.service

django-DefectDojo/dojo/importers/default_reimporter.py

Lines 337 to 338 in 9d661d7

	if self.service is not None:
	unsaved_finding.service = self.service

[Maffooch]

So it seems like this migration would erase data intentionally set by users...

[manuel-sommer]

Is there a possibility to distinguish between the two ways?