Same vulnerability is reported several times

[lsoumille]

Current Behavior

In our DependencyTrack instance for some components, we have duplicates vulnerability reports. See associated screenshots.

After digging in DependencyTrack databases we can several entries in the table COMPONENTS_VULNERABILITIES but we don't understand how that's possible.

This is issue as we are using these thresholds in build gates.

Steps to Reproduce

1. We were not able to reproduce it for distinct components, it seems to appear in a non deterministic way.

Expected Behavior

I want to have only one entry per vulnerability in DependencyTrack report

Dependency-Track Version

4.5.x

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

10.18

Browser

N/A

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this defect was already reported

[nscuro]

After digging in DependencyTrack databases we can several entries in the table COMPONENTS_VULNERABILITIES but we don't understand how that's possible.

Would it be possible to share what exactly you saw there?

Technically the same vulnerability being reported for the "same" component can happen when there are duplicate components in the projects being analyzed. But if the same vulnerability is assigned multiple times to the same component (as in, same database ID), that should definitely not happen.

[lsoumille]

Hi @nscuro

Thanks for your answer. I have double checked and for case we have:

• For a vulnerability a unique entry in vulnerability table
• For the corresponding project, we have a unique component in the table and in the BOM
• We have 2 entries in COMPONENT_VULNERABILITIES
• We see 4 times the vulnerability reported in DependencyTrack UI

We might have consistency issue in our database issue. Do you know how we can return in normal state ?

[nscuro]

We will want a similar treatment as https://github.com/DependencyTrack/dependency-track/pull/4837 for the COMPONENT_VULNERABILITIES table:

• Clean up duplicates prior to upgrade.
• After / during upgrade, create a primary key to prevent future dupes on the database level.
• Use Sets rather than Lists in Java code to enforce uniqueness in the application as well.