Display required/optional/excluded scopes differently in Dependency Graph tab and Components tables

[jimklimov]

Current Behavior

The CycloneDX spec allows to treat components as required (during described program's run-time) in the BOM document, or assign some other "scope" to them, as detailed at (currently) https://cyclonedx.org/docs/1.6/json/#components_items_scope

For example, we can keep track of excluded dependencies used in unit-testing but also know they are not delivered to end-user builds. They can become a license liability or a vulnerability of the CI farm used by the project (leak credentials etc.), but not immediately be a problem for end-users of the component or software product overall.

Likewise, an optional component might describe some facility provided by the run-time implementation (e.g. "some syslog server") but not delivered so not described in detail as part of the program the BOM document is about.

NOTE: I am not sure if Dependency-Track server and data model cares about "scope" at all at the moment, at least issue #3385 seems to be just about that and is still open (at least, UI of DT 4.9.1 and DT 4.11 indeed does not allow setting or seeing the components' scope value).

Proposed Behavior

When displaying the Dependency Graph and Components tables, provide a separate CSS style (with different border or background coloring by default), and/or column (in case of table), allowing to quickly differentiate parts of the run-time footprint from things that are just nice to know about.

In the Dependency Graph visualization at least, it makes sense to further apply a mix of styles (or a separately named style) for graph nodes that are not required by the top level node. For example, a test library might have a number of dependencies which it requires, but as long as this test library is "excluded" or "optional" for the final product - so are the use-cases of its dependencies. The same deps however may elsewhere in the path be "required" all the way to the top, and in those graph nodes would be rendered visually differently.

This information (whether the component has at least one "required" path to the top or is always optional/excluded) would also be useful in the Components table, especially in the Project/Audit Vulnerabilities tab.

This should help with manual analysis of the reported vulnerabilities to "something used in this project", and especially to quickly gauge their impact.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested