Issues with Dependency Check Imports Closing Findings in Unrelated Tests During Jenkins Pipeline Runs

Andre S. · 2026-02-20T05:16:53.056Z

Is there any known issue with imports closing findings in tests where they are not imported to? We have a lot of tests which are based on Dependency Check reports. All imports are done by Jenkins pipelines. Yesterday we set up a new pipeline and the first import of an empty DC report closed a bunch of findings a test which was not addressed by the import. The second run closed again some findings but this time it was a test which was not affected by the first import. I can't see the import in the history of the wrong test, but I can see them in the reimport history on the affected findings within the tests. I can provide some screenshots and logs from our Jenkins if needed. I guess I have seen this before, but hadn't the time to investigate.

Issues with Dependency Check Imports Closing Findings in Unrelated Tests During Jenkins Pipeline Runs | DefectDojo Community

6 comments

· Sorted by Oldest

Valentijn S.
·
·
If you use close_old_findings on an import, it will close any findings that are no longer in the scan report that is being imported (based on the deduplication algorithm). This can happen on engagement scope or product scope. Is this what could be happening? https://docs.defectdojo.com/open_source/archived_docs/usage/features/#deduplication

Andre S.

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?

Valentijn S.
·
·
Reimports do not affected other tests. The initial reimport on a non-existing test will become an Import behind the scenes. I haven't had this report before but my first though would be that this is something to think about. Maybe in this scenario DD should not close any old findings. We could leave this a responsibility of the client/user, but that would mean the client would have to know whether this is a first time import or a reimport which kinda defeats the purpose of having the "one api call to rule them all" approach.
Andre S.
·
·
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?
Valentijn S.
·
·
Yes please.
Andre S.
·
·
https://github.com/DefectDojo/django-DefectDojo/issues/14353

Valentijn S.
·
·
If you use close_old_findings on an import, it will close any findings that are no longer in the scan report that is being imported (based on the deduplication algorithm). This can happen on engagement scope or product scope. Is this what could be happening? https://docs.defectdojo.com/open_source/archived_docs/usage/features/#deduplication

Andre S.

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"

Valentijn S.
·
·
Reimports do not affected other tests. The initial reimport on a non-existing test will become an Import behind the scenes. I haven't had this report before but my first though would be that this is something to think about. Maybe in this scenario DD should not close any old findings. We could leave this a responsibility of the client/user, but that would mean the client would have to know whether this is a first time import or a reimport which kinda defeats the purpose of having the "one api call to rule them all" approach.
Andre S.
·
·
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?
Valentijn S.
·
·
Yes please.
Andre S.
·
·
https://github.com/DefectDojo/django-DefectDojo/issues/14353