Andre S.

Interesting idea. How does deduplication decide which finding is the active (original) one? I could imagine some kind of priority could help. For example I can add a priority on my tests and engagement and the finding which is in the highest priority group become the original/active finding. For this case there needs to be a mechanism to switch the original/active finding in a cluster.

https://github.com/DefectDojo/django-DefectDojo/issues/14353

I have reproduced this by creating a new test via "Import Scan Results" in the engagement. I added an empty Dependency Check report and the test has one "import" which closed 24 findings. Should I open an Issue in GitHub?

Maybe. I use the option close_old_findings and use deduplication on engagement scope. This was the initial reimport call (the report has no findings).

curl --fail --location --request POST https://.../api/v2/reimport-scan/ --header Authorization: Token **** --form minimum_severity="Info" --form active="true" --form verified="true" --form scan_type="Dependency Check Scan" --form test_title="be-collaboration - Dependency Check Scan" --form product_type_name="Portal" --form product_name="BPC" --form engagement_name="support/4.2.x" --form auto_create_context="true" --form skip_duplicates="true" --form deduplication_on_engagement="true" --form close_old_findings="true" --form branch_tag="support/4.2.x" --form commit_hash="d2bcb5c8d3385df8ca5b3c3f6d652d07bd7c1489" --form build_id="1" --form group_by="component_name+component_version" --form file=@".../workspace/target/dependency-check-report.xml"

It seems that this import closed all open findings with the type "Dependency Check Scan" in this engagement. This is suprissing because I have 20 tests based on Dependency Check imports with at least one import a day within this engagement. None of these imports affected another test. Maybe there is a problem with the very first import?

I raised an issue for this problem https://github.com/DefectDojo/django-DefectDojo/issues/14345 and provided a PR https://github.com/DefectDojo/django-DefectDojo/pull/14346

I have looked into a finding imported by DT and the parse. I think the DT parser needs some fixes. Before I go further, can you give me some details? The finding model has the fields cve and vuln_id_from_tool. What is the difference? Are there some recommendations how to use them? Is there a specific parser which can be used as a best practice example?

Can I see in DD if unique_id_from_tool is set on a finding?

I have checked the internal DT uuid. Is is already the "Vuln ID from tool" in the finding. So we only need to set the DEDUPE_ALGO_HASH_CODE. We use DD in K8s with Helm. I'm not sure. Would it be enough to add this in my helm configuration?

extraConfigs:
  DD_DEDUPLICATION_ALGORITHM_PER_PARSER: '{"Dependency Track Finding Packaging Format (FPF) Export": "DEDUPE_ALGO_UNIQUE_ID_FROM_TOOL_OR_HASH_CODE"}'