Open sephiroth-j opened 1 year ago
I think this was a design choice, at least for the first iteration of alias functionality. The current database design around doesn't lend itself very well to easily/efficiently retrieve affected projects including projects affected by aliases.
A naiv approach would be
And I think that would be quite okay, assuming that V has only one or two aliases.
p.s.
https://github.com/DependencyTrack/dependency-track/blob/25cf930e1b517130c7884354d4d94affe944a3d2/src/main/java/org/dependencytrack/persistence/VulnerabilityQueryManager.java#L475
https://github.com/DependencyTrack/dependency-track/blob/25cf930e1b517130c7884354d4d94affe944a3d2/src/main/java/org/dependencytrack/persistence/VulnerabilityQueryManager.java#L490-L493
Why no just using Set<Project>
for projects
right from the start?
Current Behavior
If a vulnerability has an alias (e.g. CVE-2023-29197 and GHSA-wxmh-65f7-jcvw), then the backend response of
/api/v1/vulnerability/source/NVD/vuln/CVE-2023-29197/projects
andapi/v1/vulnerability/source/GITHUB/vuln/GHSA-wxmh-65f7-jcvw/projects
will not return the same projects.Steps to Reproduce
Expected Behavior
The projects affected by the alias vulnerabilities should be the same.
Dependency-Track Version
4.8.2
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
No response
Browser
Google Chrome
Checklist