Skip to content

Aliases for internal vulnerabilites #5699:Fix suggestion - #5709

Closed
anton-jj wants to merge 5 commits into
DependencyTrack:masterfrom
anton-jj:master
Closed

Aliases for internal vulnerabilites #5699:Fix suggestion#5709
anton-jj wants to merge 5 commits into
DependencyTrack:masterfrom
anton-jj:master

Conversation

@anton-jj

@anton-jj anton-jj commented Jan 19, 2026 •
edited
Loading

Copy link
Copy Markdown

Description

This is a suggestion on solution for aliases for connecting internal aliases with existing CVE, GHSA, OSV.

Addressed Issue

Fixes #5699,
Fronted issue: DependencyTrack/frontend#458

Additional Details

This is a suggestion on solution for aliases, issue with this is that if a internal alias is related to a CVE and GHSA if one off those is removed from the internal alias the relationship between those are removed (CVE -> GHSA).
This does not affect the current frontend, since alias for internal vulnerabilities are disabled.
I will make a PR for the frontend also adding needed functionality.

Checklist

  • I have read and understand the contributing guidelines
  • This PR fixes a defect, and I have provided tests to verify that the fix is effective
  • This PR implements an enhancement, and I have provided tests to verify that it works as intended
  • This PR introduces changes to the database model, and I have added corresponding update logic
  • This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

@owasp-dt-bot

owasp-dt-bot commented Jan 19, 2026 •
edited
Loading

Copy link
Copy Markdown

✅ Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@anton-jj anton-jj mentioned this pull request Jan 19, 2026
Closed
1 of 2 tasks
Anton Jäppinen Johansson added 5 commits January 26, 2026 09:26
Anton Jäppinen Johansson
Add alias handling during vulnerability creation
7fab8d6 
Improve vulnerability creation by validating alias data and synchronizing the first provided alias with the persistence layer. This ensures that internal, CVE, GHSA, and OSV identifiers are captured consistently when aliases are supplied. The update also prevents missing or incomplete alias information from silently passing through the creation workflow.

Signed-off-by: Anton Jäppinen Johansson <antja@westermo.com>
Anton Jäppinen Johansson
Update alias synchronization for vulnerability updates
44d30c1 
Ensure alias data is validated and consistently updated when modifying an existing vulnerability. The logic now initializes missing alias lists, applies incoming alias fields when provided, and synchronizes the resulting alias with the persistence layer. This prevents stale or incomplete alias records from remaining attached to updated vulnerabilities.

Signed-off-by: Anton Jäppinen Johansson <antja@westermo.com>
Anton Jäppinen Johansson
Clear internal alias ID on vulnerability deletion
052f6a1 
Remove the internal identifier from the first alias when deleting an internal vulnerability. This prevents stale alias references from remaining after the vulnerability record is removed and ensures that alias data does not incorrectly point to a non‑existent internal vulnerability.

Signed-off-by: Anton Jäppinen Johansson <antja@westermo.com>
Anton Jäppinen Johansson
Small changes on getting aliases
4170ba2 
Small change to get the aliases instead of getting the whole vulnerability again

Signed-off-by: Anton Jäppinen Johansson <antja@westermo.com>
Anton Jäppinen Johansson
Small changes update vulnerability
25c2957 
updated synching aliases with jsonVuln instead of persistentVuln

Signed-off-by: Anton Jäppinen Johansson <antja@westermo.com>
@cbarthhilscher

cbarthhilscher commented Aug 14, 2026

Copy link
Copy Markdown

We're also currently missing this feature. Is there a reason why the pull request hasn't been merged yet?

@tikri

tikri commented Oct 7, 2026

Copy link
Copy Markdown

Hi and thanks for working on this! I'm also interested in this feature and looked into why the PR may have stalled.

As far as I can tell, this PR was written against the v4 alias model (VULNERABILITYALIAS, VulnerabilityAlias, qm.synchronizeVulnerabilityAlias(...)), and it targets master. On main (v5) this model has been replaced by the one described in ADR-014: aliases now live in VULNERABILITY_ALIAS (groups) and VULNERABILITY_ALIAS_ASSERTION, where every alias relationship is recorded together with an asserter. I could not find synchronizeVulnerabilityAlias on main anymore, so the PR probably can't be rebased as-is.

I also checked the current behavior against 5.1.2 and it matches what's described in #5699.

So for a v5 solution, the missing piece would probably be an asserter for aliases set via the REST API (e.g. something like API or INTERNAL), with the sync logic from ADR-014 replacing only the assertions of that asserter. That would also address the limitation mentioned in the PR description (removing one alias breaks the relationship between the others), since assertions track provenance.

@nscuro

nscuro commented Oct 17, 2026

Copy link
Copy Markdown
Member

Thanks for the contribution, apologies we didn't get to it.

Since this PR was raised, we released Dependency-Track version 5, which now lives on main.
The master branch is frozen and no longer accepts changes, so this PR cannot be merged.
See V5_MIGRATION.md for details.

Because of this, we're closing all PRs that are still open against master.
Due to many changes in v5, simply re-targeting PRs against main is very unlikely to work.

If you believe your proposed change is still worth having, here's what you can do:

  • For v5: Re-do the change on top of main, and open a new PR against it.
    Check first whether main already covers what you need, since a lot of code has been rewritten.
    Substantial changes now need an accepted ADR before the implementation can be merged,
    see CONTRIBUTING.md.
  • For v4: Until its end of life in December 2026, v4 only receives security and bug fixes on the 4.14.x branch.
    If your change is one of those, open a new PR against 4.14.x.

Thanks again for your time and effort!

@nscuro nscuro closed this Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Aliases for internal vulnerabilites

5 participants

@anton-jj @owasp-dt-bot @cbarthhilscher @tikri @nscuro