Duplicate Vulnerabilities in Dependency Check Scan Started Occurring Since April – Causes and Fixes?

·May 20, 2026 08:26 AM·

Hello, I'm using DD with scan_type=Dependency Check Scan to reimport scan results from org.owasp:dependency-check-maven plugin. It worked as expected for almost a year now. But since around mid of April it produces a lot of duplicate findings for each found vulnerability. It looks to me as if one entry is created for each of the related dependencies in addition to the actual vulnerable dependency. This produces a lot of noise in DD. I already tried to update DD and the Dependency Check maven plugin to the latest versions but this didn't change anything. I didn't change my deduplication configs so I don't understand why it started to behave differently. What could be the reason for this change in behavior in April? Did anyone of you experience something similar and how did you fix it? Thank you

4 comments

· Sorted by Oldest

Valentijn S.
·
(edited)·
It sounds like you are reporting that you upgraded defect dojo mid april and now you are seeing different behaviour. Is that correct? There haven't been any logic changes to the dependency check parser for a long time (>2 years). So I suspect something changed in the dependency check scanner or the deployment that you are scanning. Are you able to reproduce the old vs new behaviour in some way? Or do you have a sample file that shows a behaviour that should be changed regardless of the past? The parser intentionally creates a finding for each instance of a vulnerability as it is not uncommon for each instance to need their own fix. Some parsers have a detailed mode and a non detailed mode, maybe we could do something with that for the dependency check parser if we have convincing arguments.
Valentijn S.
·
(edited)·
As I had some tokens left on my Claude limit for today: Hi, thanks for the detailed report. I looked into this and I don't think DefectDojo changed the behavior here — the parser logic that produces these findings has been in place since the v6.0.0 related-dependency support and hasn't changed in April. What's happening OWASP Dependency-Check groups multiple jars that share the same content (identical hash) under a <relatedDependencies> block on a single dependency. For each vulnerability, our parser intentionally creates:
one finding for the main vulnerable dependency, and
one additional finding foreachrelated dependency that has afileName.
These related findings get the related tag. They carry the same title and CVE as the main finding but a different file path (the related jar's filename). Because the Dependency Check dedupe key is title + cwe + file_path, the differing file path means they are treated as distinct findings rather than being merged — which is why they show up as what looks like duplicates. Why it started in April for you (most likely) Since the parser behavior didn't change, the trigger is almost certainly on the report side: your build now contains more jars that Dependency-Check groups as related (e.g. duplicate or shaded jars on the classpath, or new transitive dependencies with identical content). That's also why updating the DC plugin didn't help — relatedDependencies is core DC behavior across versions. Your dedupe config is not the cause. How to confirm
1.
Open the XML report and check for<relatedDependencies>/<relatedDependency>nodes — the count should roughly match the extra findings.
2.
Confirm the "duplicate" findings carry therelatedtag in DefectDojo.
How to reduce the noise
Filter or hide findings with therelatedtag in your views/reports.
Address it at the source by removing duplicate jars from the classpath (shaded artifacts, multiple copies of the same jar), which removes therelatedDependenciesfrom the report.
If you can share a (sanitized) snippet of the XML showing the relatedDependencies block for one of the affected vulnerabilities, I can confirm exactly what's being grouped.
Holger
·
(edited)·
It sounds like you are reporting that you upgraded defect dojo mid april and now you are seeing different behaviour. Is that correct?
No. The new behavior started without any upgrades. I tried to fix it by upgrading. But this didn't help. But I think I found out now what changed: I had so many related findings recently because the findings were reported for org.springframework.boot:spring-boot and org.springframework:spring-core . Both have around 10 <relatedDependency> entries reported from Dependency-Check. This was different for other/older findings which were caused by different jars (not spring-boot or spring-core) and had way less <relatedDependency> entries. That's why the noise increased and I thought the behavior of the import changed. But actually only the vulnerable jars had changed -> and this triggered the noise. I've attached an example file stripped down to only one dependency (spring-boot in this case). This dependency has 11 <relatedDependency> entries and 8 <vulnerability> entries. It creates 96 findings for those 8 vulnerabilities when imported. IMO it would sufficient to create 8 findings (simply on the actual <dependency>) but skip all <relatedDependency>.
OWASP Dependency-Check groups multiple jars that share the same content (identical hash) under a <relatedDependencies> block on a single dependency
That seems to be a misconception. <relatedDependencies> seem not to contain "multiple jars that share the same content (identical hash)" but actually contain completely different jars which are somehow related to the main vulnerable one. Is it an option to change the parser to skip all <relatedDependency> entries?
Valentijn S.
·
(edited)·
I dived into this a bit more and it turns out the relatedDependencies can contain other jars with the same hash but in a different location. But it can also contain other jars the map to the same CPE, which is the case in the example provided. I created a PR to reduce the number of findings in cases where can do this without losing information: https://github.com/DefectDojo/django-DefectDojo/pull/14941
❤️1

Duplicate Vulnerabilities in Dependency Check Scan Started Occurring Since April – Causes and Fixes? | DefectDojo Community

Valentijn S.
·
(edited)·
It sounds like you are reporting that you upgraded defect dojo mid april and now you are seeing different behaviour. Is that correct? There haven't been any logic changes to the dependency check parser for a long time (>2 years). So I suspect something changed in the dependency check scanner or the deployment that you are scanning. Are you able to reproduce the old vs new behaviour in some way? Or do you have a sample file that shows a behaviour that should be changed regardless of the past? The parser intentionally creates a finding for each instance of a vulnerability as it is not uncommon for each instance to need their own fix. Some parsers have a detailed mode and a non detailed mode, maybe we could do something with that for the dependency check parser if we have convincing arguments.
Valentijn S.
·
(edited)·
As I had some tokens left on my Claude limit for today: Hi, thanks for the detailed report. I looked into this and I don't think DefectDojo changed the behavior here — the parser logic that produces these findings has been in place since the v6.0.0 related-dependency support and hasn't changed in April. What's happening OWASP Dependency-Check groups multiple jars that share the same content (identical hash) under a <relatedDependencies> block on a single dependency. For each vulnerability, our parser intentionally creates:
one finding for the main vulnerable dependency, and
one additional finding foreachrelated dependency that has afileName.
These related findings get the related tag. They carry the same title and CVE as the main finding but a different file path (the related jar's filename). Because the Dependency Check dedupe key is title + cwe + file_path, the differing file path means they are treated as distinct findings rather than being merged — which is why they show up as what looks like duplicates. Why it started in April for you (most likely) Since the parser behavior didn't change, the trigger is almost certainly on the report side: your build now contains more jars that Dependency-Check groups as related (e.g. duplicate or shaded jars on the classpath, or new transitive dependencies with identical content). That's also why updating the DC plugin didn't help — relatedDependencies is core DC behavior across versions. Your dedupe config is not the cause. How to confirm
1.
Open the XML report and check for<relatedDependencies>/<relatedDependency>nodes — the count should roughly match the extra findings.
2.
Confirm the "duplicate" findings carry therelatedtag in DefectDojo.
How to reduce the noise
Filter or hide findings with therelatedtag in your views/reports.
Address it at the source by removing duplicate jars from the classpath (shaded artifacts, multiple copies of the same jar), which removes therelatedDependenciesfrom the report.
If you can share a (sanitized) snippet of the XML showing the relatedDependencies block for one of the affected vulnerabilities, I can confirm exactly what's being grouped.
Holger
·
(edited)·
It sounds like you are reporting that you upgraded defect dojo mid april and now you are seeing different behaviour. Is that correct?
No. The new behavior started without any upgrades. I tried to fix it by upgrading. But this didn't help. But I think I found out now what changed: I had so many related findings recently because the findings were reported for org.springframework.boot:spring-boot and org.springframework:spring-core . Both have around 10 <relatedDependency> entries reported from Dependency-Check. This was different for other/older findings which were caused by different jars (not spring-boot or spring-core) and had way less <relatedDependency> entries. That's why the noise increased and I thought the behavior of the import changed. But actually only the vulnerable jars had changed -> and this triggered the noise. I've attached an example file stripped down to only one dependency (spring-boot in this case). This dependency has 11 <relatedDependency> entries and 8 <vulnerability> entries. It creates 96 findings for those 8 vulnerabilities when imported. IMO it would sufficient to create 8 findings (simply on the actual <dependency>) but skip all <relatedDependency>.
OWASP Dependency-Check groups multiple jars that share the same content (identical hash) under a <relatedDependencies> block on a single dependency
That seems to be a misconception. <relatedDependencies> seem not to contain "multiple jars that share the same content (identical hash)" but actually contain completely different jars which are somehow related to the main vulnerable one. Is it an option to change the parser to skip all <relatedDependency> entries?
Valentijn S.
·
(edited)·
I dived into this a bit more and it turns out the relatedDependencies can contain other jars with the same hash but in a different location. But it can also contain other jars the map to the same CPE, which is the case in the example provided. I created a PR to reduce the number of findings in cases where can do this without losing information: https://github.com/DefectDojo/django-DefectDojo/pull/14941
❤️1