Add "Show in Dependency-Graph" Button in "Affected Projects" List

[rbt-mm]

Description

This PR adds the Show in Dependency-Graph button to the every project in the Affected Projects tab of a vulnerability, but only if the affected project has a dependency graph.
Clicking the button redirects the user to the projects dependency graph and highlights the affected component.

Addressed Issue

DependencyTrack/frontend#533

Additional Details

Frontend PR: DependencyTrack/frontend#573

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

[rkg-mm]

@nscuro any reason for not merging this?

[nscuro]

@rkg-mm No particular reason other than me overlooking it. I'll have a look in the coming days. Thanks for the ping.

[rkg-mm]

@nscuro ok thanks, just wanted to make sure we didn't miss something :D

[nscuro]

I think there is a caveat here:

The modified endpoint returns projects affected by a given vulnerability. It is possible that multiple components in a project are affected, but this implementation does not cover this case and will only ever yield a single component per project.

Few options I see:

• We return the UUIDs of all affected components for a project. Clicking the button in the UI will then go on to highlight all of them in the graph.
• We keep it at a single component per project, but clearly indicate that it's only one of potentially multiple. In this case, we need to make sure that it's deterministically the same component UUID when requesting the endpoint multiple times.

[rkg-mm]

@nscuro you are right. Which solution do you prefer?

[nscuro]

@rkg-mm I would love to see the former option, as the other can be confusing. But have not looked into how much effort it is to support this in the dependency graph view.

[rbt-mm]

@nscuro I think these are probably all the steps necessary to implement the new solution:

Backend

• Return all the UUIDs of all affected components for a project in the Vulnerability API endpoint.
• Modify the method to get the dependency graph of a component to accept an array of components instead of just a single component.
• Modify the SQL statement to get the parent nodes of every component in the array.
  • This will create a new possible case where a searched UUID can also be the parentNode of another searched UUID. I don't think that this case will create problems, but a new test should probably be written to cover it.

Frontend

• Clicking the Show in dependency graph button must redirect to a project's dependency graph and the URL must contain the UUID of every component affected by the Vulnerability.
  • The different UUIDs in the URL need to be separated by some kind separator (e.g. /<projectUUID>/dependencyGraph/<componentUUID1>|<componentUUID2>)
  • The maximum length of a URL in the address bar is 2048 characters so we shouldn't run into any problems here.
• The code that sets the labels of the dependency graph nodes must be modified to check for every UUID in the URL so that every node that contains any of these UUIDs can be highlighted.
• The current message, which is displayed when the UUID in the URL cannot be found in the dependency graph, only says Dependency could not be found in dependency graph. Maybe for multiple UUIDs in the URL, this needs to be changed to specify which of the UUIDs couldn't be found in the dependency graph.

I think this would probably need 1 or 2 days to implement, but unfortunately I currently cannot allocate my time to implement this myself.

[nscuro]

Thanks for those details @rbt-mm, very helpful! We also can't work on this within the 4.10 milestone, but should be able to in 4.11 if needed. I'm thus pushing this to 4.11.

[rkg-mm]

@nscuro I made the discussed improvements. I wasn't able to push on the original branch from @rbt-mm so I created a new PR which replaces this here: #3285

I also improved the performance of the tree by a lot and refactored some code to simplify it.