🎉 Advance reimport to update fix_available field #12633

[manuel-sommer]

• I advanced fix_available to be updated within each reimport: Add "has fix" filter for CVE finding #12633 (comment)
• I added field fix_version to populate a dedicated fixed version in the header of a finding. This field can also be used to be updated equal to fix_available within the reimport. An example screenshot can be found here:

- I added anchore grype to populate these fields

#12633 (comment)

[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 modifies several sensitive files (e.g., dojo/importers/default_reimporter.py, dojo/models.py, templates and migrations), and the scanner flags risky edits to those codepaths; it also introduces two substantive issues: a potential denial-of-service where anchore_grype can create a fix_version string longer than the DB field (causing a DataError during import), and a re-import business logic flaw that allows users who can import scans to change fix_available/fix_version on existing findings, enabling privilege escalation.

🔴 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.

🔴 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.

🔴 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.

🔴 Configured Codepaths Edit in dojo/models.py

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/templates/dojo/view_finding.html

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/models.py

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/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.

🔴 Configured Codepaths Edit in dojo/templates/dojo/view_finding.html

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/db_migrations/0245_finding_fix_version.py

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

Denial of Service via DataError in dojo/tools/anchore_grype/parser.py

Vulnerability

Denial of Service via DataError

Description

The fix_version field in the Finding model has a max_length of 100 characters. The anchore_grype parser constructs the fix_version string by joining multiple fix versions with a comma and space (, ). If a Grype report contains a vulnerability with a list of fix versions that, when joined, exceed 100 characters, attempting to save this Finding object to the database will result in a DataError. This error is not explicitly handled in the get_findings method of the parser, which means the entire scan import process could fail, leading to a denial of service.

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

Lines 133 to 136 in 95bf03a

	fix_version = ", ".join(vuln_fix_versions)
	for fix_version in vuln_fix_versions:
	finding_mitigation += f"\n- {fix_version}"

Business Logic Flaw (Privilege Escalation) in dojo/importers/default_reimporter.py

Vulnerability

Business Logic Flaw (Privilege Escalation)

Description

The re-import process in DefectDojo allows a user with permissions to import scans to update the fix_available and fix_version fields of existing findings. This means that if a user has the ability to re-import a scan, they can potentially alter the fix status and version of a vulnerability, even if they lack direct permissions to manually edit these fields on a finding. This could bypass intended review or approval workflows for vulnerability remediation.

django-DefectDojo/dojo/importers/default_reimporter.py

Lines 482 to 484 in 95bf03a

	if existing_finding.fix_available != unsaved_finding.fix_available:
	existing_finding.fix_available = unsaved_finding.fix_available
	existing_finding.fix_version = unsaved_finding.fix_version

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

[manuel-sommer]

Please review @valentijnscholten

[manuel-sommer]

Another point @valentijnscholten :
I can also remove the mitigation field from the deduplication settings in general and update it as well. Also take a look here:
#13053
#13055
With these two PRs, all mitigation fields in use would be removed from HASHCODE_FIELDS_PER_SCANNER in settings.dist.py
This enables us to update the mitigation field also as soon as a fix_available changes. These two fields often correlate.

[valentijnscholten]

Maybe start with just the fix_available field first as we are all in agreement that is good change to make.

[manuel-sommer]

Could we release this for the next release on Monday @mtesauro ?

[valentijnscholten]

The fix_version should contain 1 or more versions in which the issue is fixed. If it is a code change or configuration change or something else which is not about updating to a newer version we should use the mitigation field (or sometimes it's part of the description)

[manuel-sommer]

The fix_version should contain 1 or more versions in which the issue is fixed. If it is a code change or configuration change or something else which is not about updating to a newer version we should use the mitigation field (or sometimes it's part of the description)

Then, @valentijnscholten I would suggest to remove it as only a small number of vuln scanners post multiple fixed versions. Also, we can put that information to mitigation

[valentijnscholten]

What do you want the remove? I think the fix_version field is useful to have as can be a column on reports/exports/dashboards.

[manuel-sommer]

Ok, sounds legid

[manuel-sommer]

fyi @kiblik

[manuel-sommer]

Would be awesome if we could get this on the road for this release @mtesauro

[valentijnscholten]

@manuel-sommer Looks good. Can you update the docs/content/en/connecting_your_tools/import_scan_files/using_reimport.md doc file to also mention the fix_version field.

(And rebase the migration)

[manuel-sommer]

@manuel-sommer Looks good. Can you update the docs/content/en/connecting_your_tools/import_scan_files/using_reimport.md doc file to also mention the fix_version field.

(And rebase the migration)

done @valentijnscholten