Grype Import in DefectDojo Creates Fewer Findings

[Kasyap7]

Hi Team,
I'm migrating from Anchore Engine to Anchore Grype for vulnerability scanning and encountering an issue with finding counts in DefectDojo. Both scanners produce reports with identical vulnerabilities, but DefectDojo creates significantly fewer findings when importing Grype reports compared to Anchore Engine reports.

Environment Details
DefectDojo Version: v2.53.0
Scanner Migration: Anchore Engine → Grype
Report Format: JSON
Import Method: API upload

What I've Tried
Deduplication Settings: Modified settings_dict.py to include file_path in Grype deduplication configuration, but I am still unable to get the accurate count of findings in DefectDojo.

Defectdojo UI count

Grype report used for testing (201 issues in report):
grype_registry.k8s.io__etcd--3.6.4-0.json

Question
What specific logic can I add to the defectdojo Grype parser or configuration to ensure I get the accurate count?

[valentijnscholten]

The Anchore Grype parser has an internal deduplication which you cannot influence via settings:

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

Line 188 in 3907211

dupe_key = finding_title

And finding_title is "{vuln_id} in {artifact_name}:{artifact_version}" (line 87).

I think a PR that adds file_path to the internal dedupe key would be something we could accept.

[Kasyap7]

@valentijnscholten
Created a PR with changes #14592

[Kasyap7]

Hi @valentijnscholten

I have not yet added file_path to HASHCODE_FIELDS_PER_SCANNER for Anchore Grype in settings.dist.py , and I want to flag a concern before doing so.

The problem for existing users:

Right now, existing DefectDojo installations have Grype findings stored with a hash_code computed without file_path. If we add file_path to HASHCODE_FIELDS_PER_SCANNER:

• When users reimport a Grype scan, the new findings will get a different hash_code.
• DefectDojo won't recognize them as the same finding — old findings will be closed/mitigated, new ones created from scratch.
• Users lose all their previous triage history (notes, false positives, risk acceptances).

The fix would be to manually recompute hashes after upgrading:
But this doesn't happen automatically.

docker compose exec uwsgi python manage.py dedupe --parser "Anchore Grype" --hash_code_only

Questions:
Should we add file_path to HASHCODE_FIELDS_PER_SCANNER in this PR, with a note in the upgrade instructions or release notes? Or is it better to keep this PR focused on just the parser fix?

[valentijnscholten]

Good thoughts, can you post on the PRs o we have one place for discssion?