Projects view should roll up to the parent project level and show the latest version

[Drewster727]

Current Behavior:

The projects view shows all versions of all projects. This is cumbersome and unnecessary.

Proposed Behavior:

If I have "Application X" with versions 1.0 and 2.0. I should only see one entry in the projects view showing "Application X version 2.0" -- when I click that project to go to it's details page, I should be able to flip between 1.0 and 2.0 to see the dependencies/components/vulnerabilities present in each.

Thanks, Drew

[llamahunter]

I think this is kind of an important feature, especially in continuous delivery environments. Every build is a new 'version' that can go to production if it passes all it's promotion gates. I like the horizontal history view you get on vulnerabilities if working on multiple builds of a single version (which is not very CD), but there is no way to dive in to the vulnerabilities of a specific build of that single version.

On the other hand, making a new version of every builds makes the Projects page unmanageable and practically useless, as it is just pages and pages of versions of 'aaaapp-test' or whatever earliest in the alphabet.

It would be nice if there were a 'best of both worlds' view by inserting a application roll up layer into the navigation hierarchy that had a horizontal history graph of CVEs by last build of each version of the app, and then be able to click down into each version in case it had multiple builds.

[cmenzi]

I have exactly same issue. We release for example and sdk. Every master build is a beta / pre-release builds (e.g 1.3-beta0003). Once they are ready to release, we tag them with 1.3 which then becomes a released version of the sdk.

It's always the same project (project-key) with different versions and version history.

It's like

[stevespringett]

The persistent snapshot to release is actually easy. You would never want to create a new version for every build as you'll likely loose all your audit history when doing it (if you don't do a clone first). Certainly not a best practice, you'll start to kill the performance of DT over time, etc, etc.

You can dive into the vulnerabilities of a specific build using the Jenkins plugin. That capability exists today which uses the Findings API and saves the results into per-build Jenkins actions. If you're using other CI servers, then perhaps there's a need for plugins for those. I will not be taking that on, but perhaps someone from the community can.

Using the Findings API, it would also be possible to create GitHub actions that would execute on pull requests for example. So you could present the findings to the developer in their PR and fail a check if you wanted. I haven't personally done it, but perhaps someone from the community can work on it.

Flipping between project versions is already possible when viewing the project. There's a drop down on the project page to select other versions. If anyone has recommendations on how that can be improved, please provide some mockups so we can iterate on that. The next gen UI is in development and is a complete rewrite. So if UI modifications are wanted, please see refer to https://github.com/DependencyTrack/frontend

[llamahunter]

Well, for the 'project' view, I would like there to be a history graph of the last audit of every version. I would like that graph to be clickable, so that I could dive down into the version view. Also I'd like a list of all the versions below the single project view graph, with a search field to find a specific version.

For a Continuous Delivery type of setup, there is no specific 'release' build of the code. Each build becomes a potential production release, based on extensive integration test results, robustness testing, product roadmap alignment, phase of the moon, and other factors. We don't know a priori when the build uploads CycloneDX info to DepTrack whether this artifact will roll all the way out to production, or just as far as staging, or whatever. Every build gets a new version number so that each artifact can be tracked.

Now, I could see how having lots and lots of versions of a project could cause some headaches for the DT UI if it doesn't take care to address that in some way. It's possible that another new feature request would be 'auto pruning' of project versions that are a) unreferenced as a dependency by anything else in DT, b) older than some certain age, c) when more than N versions of a project exist, etc. Or, perhaps there's already an API to the DT server that would let us write tools to query all the version audits and delete some of them periodically based on custom code we wrote.

[stevespringett]

history graph of the last audit of every version

Please clarify. Audit decisions can be per project or global.

We don't know a priori when the build uploads CycloneDX info to DepTrack whether this artifact will roll all the way out to production

Couldn't you add a 'release' tag to the version in DT after something has been pushed to prod? Considering you can already include tags as part of your search it should be simple to filter out released from unreleased. Also, for unused projects, you can either delete them or you can set the inactive bit. Marking a project as inactive will remove it from the projects view and you'll optionally have the ability to include inactive if you want to see those. But they'll still be there and will still impact portfolio metrics, etc.

Every build gets a new version number

Hopefully thats only in the build script and not DT. Otherwise, asynchronous tasks such as metrics, NVD updates, etc, will start to back up and take longer because the metrics will start to consume the majority of CPU and database IO resources. Also, if you're reporting portfolio risk up to an executive dashboard, your metrics will be all wrong if you have multiple project versions that are unreleased which represent no actual risk to the org.

Now, I could see how having lots and lots of versions of a project could cause some headaches for the DT UI if it doesn't take care to address that in some way.

It does. Mark them as inactive. However, the UI does not consolidate project versions into a single line item. That's an easy problem to solve if semantic versioning is used across the board. However, for projects with marketing names (XP, Vista, NT, etc), epochs (most RPM packages), IoT devices (rev 1, rev 1b, etc), it becomes a lot more complex. It's extremely difficult to know what the 'latest' version is (which is the original purpose of this ticket). I'm leaning towards making the 'latest' a simple bit field on the project which would indicate which project out of all the versions, is the latest. And of course have logic in there to ensure that for a given project by name, it can only have one 'latest' version.

It's possible that another new feature request would be 'auto pruning' of project versions

Auto-pruning unused components will be a future feature. There's a ticket open for that. Pruning projects is extremely dangerous as there's no way of reliably knowing if a project is a monolith, microservice, IoT device, or an OS somewhere running a critical business application. All of which would have different criteria for operational retirement and thus pruning from DT. The Dependency-Track API has much more capability than the UI does. Automation and custom use of the API is highly encouraged.

[jrevillard]

Hello @stevespringett,

I'm in the process of pushing the DT usage in my group and this issue puzzle me a bit... We might have a LOT of projects inside DT and I really would like to find an easy way to manage projects (with all the versions) as a real object: for ACL management etc...

For MR jobs also, it would be really interesting to be able to scan a sbom but without creating a project or version. This would be a one shot analyse just to see a result (like in SonarQube for instance)

Did you progress somehow in your reflection here ex: deactivating some projects based on regex for versions (ex: *-SNAPSHOTS) and last upload ?

Thanks, Jérôme

[msymons]

@jrevillard, the functionality that would allow scanning of an SBOM without creating a project is covered by enhancement #1125