Link a Projects as a component of another project

[thompson-tomo]

Current Behavior

User must manually calculate vulnerabilities of all projects being deployed

Proposed Behavior

I wish for the "add component" button to now have a drop-down of 2 options:

• Component
• Project

When a user selects the project option they are provided UI to select a project and version which already exists in dependency track.

The way my releases work i have multiple micro-services which are bundled together as part of a build pipeline to form 1 installer for the end user.
With the proposed approach i could select a "project" which represents my installed and see all the projects which are contributing to that installer and have install visibility into the health of that release.

Alternative option would be to allow multiple parent projects

Checklist

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

[valentijnscholten]

How would this work on SBOM upload for a project that has a dependency on another project? In the SBOM there's must a purl of that other project. But that purl can or cannot be present in DT. And if it is present, maybe the uploader does not want to link them together. Can this feature be implemented without requiring extra information in the SBOM / from the uploader?

[thompson-tomo]

I don't think we need to touch/change the SBOM based on the linking being opt-in via clicking the add component button and then selecting the project.

[valentijnscholten]

The SBOM is the single source of truth. Any components added later will be removed upon the next SBOM upload. My point was that it should be automateable to be scalable.

[thompson-tomo]

Sure I do agree that it would be very nice if the linking could be automated based on purl but establishing that connectivity would be the first key step even if manual.

[savek-cc]

Hi!
We're actually also working on a feature like this. It has already been discussed here in other issues (t.b.d. - link them to this one).
Our current working discussion is this:

DependencyTrack shall be able to use DT projects as components within another project.
Mapping shall be performed based on CPE and/or PURL assigned to the shared project and listed in the consuming projects SBOM
DependencyTrack shall offer to optionally resolve components from shared projects. (Setting on consuming project-level)
    "Resolve dependencies of shared projects": fully inherit each sub-component (including vulnerabilities) from the shared project (merge SBOM)
    "Do not resolve dependencies of shared projects": fully inherit every un-audited or affected vulnerability as a vulnerability of the shared project instead of the actual sub-component.
Option 1)
    Shared project has multiple components with multiple CVE/GHSA/...
    ALL sub-components of the shared components are copied/synced to the consuming project
    Basically ONE combined SBOM - with dependency-tree - with all resolved sub-components is created an analyzed using the standard vulnerability sources.
    Assuming spring-web is a dependency of a shared project:
    Image
Option 2)
    Shared project has multiple components with multiple CVE/GHSA/...
    List of "open" CVE/GHSA/... are inherited to the consuming project
    Inherited CVE/GHSE/... shall be based on AUDITED vulnerability list of shared project
    All vulnerabilities shall be assigned to the "component" shared project (instead of the original sub-component within the shared project)
    Image

Acceptance Criteria

Given a "main" project that uses an internal shared component, when that shared component has known vulnerabilities and the user selected to resolve sub-projects, then DepTrack lists all vulnerabilities in the shared component's dependency below the "main" project (current state)
Given a "main" project that uses an internal shared component, when that shared component has known vulnerabilities and the user selected to not resolve sub-projects, then DepTrack only lists the shared project along with its non-audited/affected vulnerabilities.
Given a project that uses another project as a component, when a user clicks on the component, then the user is redirected to the project's page (instead of the component page)

Hint: Detect and prevent circular dependencies.

[savek-cc]

References to other discussions on this topic:
#869
#2041 (comment)

[thompson-tomo]

Yes #869 is certainly connected to this, I think we should let this issue focus on making it easy to define that relationship using UI rather than uploading SBOM's.

[savek-cc]

DependencyTrack is "API first" - what speaks against identifying a project by assigning it a purl (or cpe if you must) and then including this in an SBOM of a "summary" project?
Using the UI you could just add a component with the same purl as the dt project that you assigned this purl - see #3375 (comment) for two possibilities on how to "merge" vulnerability/composition information.

[thompson-tomo]

I have no issue with the 2 options mentioned. I am just thinking about how to avoid the need to manually create an sbom for a container project which introduces greater chance of error.

My use case is I perform a release of my application. This app is made of 6 different services with each being a dedicated project in DT. In some releases all the services have a new version but in others only 1 might change hence making it easily definable in the ui is desired. After adding a new version of the master app via UI, the user could simply select the new version of the linked project from a drop-down in the edit component screen.

[savek-cc]

I think if you separate UI from actual implementation, you could get at it like this:

1. assign each of your (relevant) project a purl-string (so that is is identifiable)
2. reference those projects from another project
   a) by uploading a bom containing those purls
   b) in the UI have an additional option to reference a project for easier selection; in the end/technically this is the same as adding a component with the matching purl though.

[thompson-tomo]

Sure it should certainly appear the same when looking at vulnerabilities & dependency graph. In terms of processing the difference should be that a manually linked project should not be wiped on uploading an sbom.

[savek-cc]

I don't think that will work - as you'd need a completely different data model. It's all about SBOMs; If you manually edit that, it will be overwritten with a new upload (as is everything else). And it should - as a new upload/version might also have dependencies to later versions of another "project".

[thompson-tomo]

Ok if there is no way to have it so that a manually created component is not wiped on the upload of an sbom could there be a way in which a file (ie sbom) with components is passed to the dotnet tool so that those components can be added?

[savek-cc]

I don't know your exact setup - I'd reccomend to take that part of the SBOM (download components as SBOM, just keep the part with the manually added ones) and merge it to the automatically generated one using e.g. CycloneDX-CLI as a workflow.

[thompson-tomo]

Yes that would be possible but isn't as convenient as simply passing the path of an existing sbom (downloaded & filtered) to the dotnet tool. Your proposal adds an extra build command & requires an additional tool to be installed in the environment.

[savek-cc]

Your suggestion isn't usable in an automated way (via the API) at all though - and updating reference projects versions requires a lot of manual work.

[thompson-tomo]

My suggestion is the same as yours except I am proposing the dotnet cli tool does the merging rather introduce an additional tool