dependency-track
dependency-track copied to clipboard
Same vulnerability different databases reported twice
Current Behavior
A vulnerability which exists in multiple databases are not linked so report as 2 issues (therefore doubling risk score)
Steps to Reproduce
1.import BOM with vulnerability present that reported in NVD, GitHub and Sonatype
Expected Behavior
Vulnerability are linked and only report once
Dependency-Track Version
4.6.2
Dependency-Track Distribution
Container Image
Database Server
MySQL
Database Server Version
No response
Browser
Google Chrome
Checklist
- [X] I have read and understand the contributing guidelines
- [X] I have checked the existing issues for whether this defect was already reported
Hi, I can see the same problem. In GUI I see 10 vulnerabilities from 2 different DB sources and in API I see only 5, so somehow API is removing duplicates and GUI is not. I use api/v1/metrics/project/ for checking the statistics.
Confirming too. Image taken from audit tab showing the same vulnerability showing once per vuln repository. We can also see the matching Vulnerability/aliases values.
DT version : 4.7.1
Confirming duplication and cross-aliasing of the vuln sources/analyzers between NVD and GITHUB vuln, with the additional weirdness that:
- the NVD vuln's direct Analyzer link in the Audit tab says "OSS Index" and points to https://ossindex.sonatype.org/vulnerability/CVE-... despite it being a NVD sourced vuln
- the OSS Index' own vuln directly links to "OSS Index" too, but the link points to the always-404-ing https://ossindex.sonatype.org/vulnerability/sonatype-... (see https://github.com/DependencyTrack/dependency-track/issues/1141)
See:
Hello @here, the same thing happens to me. So? How can we fix it? Thanks in advance. 🔥
It's been some time since the issue was reported so is there any update? I would love to have this one fixed.
Note:
... (therefore doubling risk score)
The risk score is not doubled.
Please pay attention to the problem, it is still relevant
@nscuro I believe, at least for now, this duplication is by design. Would it be helpful to document this somewhere, maybe in the design decisions docs that I believe is being created for Hyades?
@valentijnscholten I guess the main problem for us is not the view but notifications. We are creating 2 jira tickets for every finding. And then I need to manually remove them. It looks like you have the way to deduplicate those findings, because API shows the right number, so why not use this algorithm when creating notifications?
I just tried this out using the latest DT Version and can confim it is still a problem. It makes maintaining VEX Data pretty tiring tbh.