autoCreateProjects and project versions

[mendorf]

Dear community,
I recently started using Dependency Track and there is one thing that I am not quite sure if configured correctly or working as designed.

I use Jenkins Dependency Track plugin to publish BOM from within our build pipelines, e.g.

dependencyTrackPublisher artifact: 'build/reports/bom.xml', projectName: 'myproject', projectVersion: imageTag, synchronous: false, autoCreateProjects: true, dependencyTrackApiKey: API_KEY

This currently leads to separate projects in the Projects overview, each having just one single version. Since I could manually "Add version" on each project, it seems to make more sense overall to have all versions consolidated under one project. I also figured that with the current setup, I am not able to suppress findings for all existing and future versions, I guess this is not intended?
What is the actual best practice for BOM uploads to Dependency Track?

What is the logic behind autoCreateProjects? Should it only be used for initial uploads, but not with CI? The docs read, that the parameter is optional. Does Dependency Track create a new project only when it does not find an existing project having the same name or UUID? Is there some high level flowchart that would help to understand the logic, or additional documentation available on how the publishing parameters will influence the assignment of the BOM to a project?

If things should work differently than described - how could I troubleshoot this?

tl;dr - how are you uploading BOMs, using UUID or project (or even parent) names from within your pipelines?

[mendorf]

fyi, found #3396 and it looks like I should rather use the project UUID for my release builds, instead of project name. It would still be beneficial to have some best practices and/or different use cases documented.

[mendorf]

according to this discussion on the Jenkins plugin repo, seems like I was setting up things correctly - each project/version combination is actually an own project list entry. I noticed that if I would use a fixed project ID instead of autocreating projects, the projects version would not update at all.

Now looking into group name configuration or parent project logic, so I could group by project name in the project list at least.

Still, I am not sure how to get risk acceptance (suppress findings) copied over into future versions, e.g. at least future minor versions, currently our product manager would have to specify risk acceptance on every new build, that would mean almost daily...

[pkunze]

Your last paragraph hits home. Did you get this to work? We are not eager to analyze hundreds of vulnerabilities on a daily basis over and over again too 😅

[black-snow]

This bit me, too. #3448 is related

When I set up DT I was thinking pretty much the same. Just post SBOM from the pipeline with a project name, the current version and the autoCreate (and perhaps a parentProjectName). I though that'd create and then update a project and within DT I'd have one project with multiple versions.

Nope, it creates new projects with new components all the time. So anything you enter manually is essentially lost with the next pipeline run.

I have now set it up to post to the project UUID with no parent, no autoCreate and just one version. I now only get the last pipeline run but at least it doesn't lose manually added license information for example ... Of course, this requires me to set up projects in DT first, then copy over the UUID. No auto-onboarding of new projects.

I think the docs should make the intended workflow clear(er). I still don't know how we're supposed to use it.

[mendorf]

FYI, I summarised some audit workflow approaches I found within other discussions here.

Apparently, things are going to change with DT v5, but the documentation could still be improved.