Parent project name is not respected

[tomkuipers]

Current Behavior

To keep track of deployed containers we created namespaces as parent projects (e.g. deptrack-dev and deptrack-prd). Namespaces can contain multiple projects - which are containers running inside the namespace (e.g. dependencytrack/apiserver, dependencytrack/frontend, aquasec/trivy). The container version is used as project version, the container name (including registry) is used as project name. For example one of the containers for service Dependency-Track and its version is dependencytrack/apiserver:4.13.6. The generated SBOM (deptrack_apiserver.json) for this specific container is uploaded with settings:

  curl -X "POST" "https://dependency-track/api/v1/bom" \
       -H 'Content-Type: multipart/form-data' \
       -H "X-Api-Key: XXX" \
       -F "autoCreate=true" \
       -F "projectName=deptrack-apiserver" \
       -F "projectVersion=4.13.6" \
       -F "parentName=deptrack-dev" \
       -F "parentVersion=parent" \
       -F "classifier=Container" \
       -F "updateParent=true" \
       -F "isLatest=true" \
       -F "bom=@deptrack_apiserver.json"

We want to organize containers (projects) in namespaces to know where they are running and which team is responsible. Running container versions can differ at some point in time. A new version is first deployed in DEV namepace (deptrack-dev) and later in PRD namespace (deptrack-prd). The SBOMs for containers are automatically generated in a CI/CD pipeline and uploaded to Depedency-Track when a new version of a container is deployed.

The issue is that parent project name is not respected. If you first upload the SBOM with projectName=deptrack-apiserver, projectVersion=4.13.6 and parentName=deptrack-dev It will correctly show under deptrack-dev. Next - when you want to deploy the same container and version to production - you use the same SBOM with projectName=deptrack-apiserver, projectVersion=4.13.6 and parentName=deptrack-prd. Now the project doesn't show under deptrack-prd but overwrites the entry (updated Last BOM import) in deptrack-dev.

Steps to Reproduce

1. create projects deptrack-dev and deptrack-prd both with version parent to reflect namespaces for DEV and PRD
2. generate the SBOM for a specific container: trivy image --format cyclonedx --skip-db-update --skip-check-update --output deptrack_apiserver.json dependencytrack/apiserver:4.13.6
3. upload the SBOM file to DEV namespace deptrack-dev:

curl -X "POST" "https://dependency-track/api/v1/bom" \
       -H 'Content-Type: multipart/form-data' \
       -H "X-Api-Key: XXX" \
       -F "autoCreate=true" \
       -F "projectName=deptrack-apiserver" \
       -F "projectVersion=4.13.6" \
       -F "parentName=deptrack-dev" \
       -F "parentVersion=parent" \
       -F "classifier=Container" \
       -F "updateParent=true" \
       -F "isLatest=true" \
       -F "bom=@deptrack_apiserver.json"

4. Project dependencytrack/apiserver:4.13.6 will show under deptrack-dev
5. Next, upload the SBOM file to PRD namespace deptrack-prd:

curl -X "POST" "https://dependency-track/api/v1/bom" \
       -H 'Content-Type: multipart/form-data' \
       -H "X-Api-Key: XXX" \
       -F "autoCreate=true" \
       -F "projectName=deptrack-apiserver" \
       -F "projectVersion=4.13.6" \
       -F "parentName=deptrack-prd" \
       -F "parentVersion=parent" \
       -F "classifier=Container" \
       -F "updateParent=true" \
       -F "isLatest=true" \
       -F "bom=@deptrack_apiserver.json"

6. Notice there is no project dependencytrack/apiserver:4.13.6 created under deptrack-prd, but the project dependencytrack/apiserver:4.13.6 under deptrack-dev is updated - the last BOM import timestamp has been updated.

Expected Behavior

The expected behaviour is to respect the parent project name. If an SBOM is uploaded with identical projectName and projectVersion, but different parentName I would expect there would be two project entries, each under their own parentName.

Dependency-Track Version

4.13.6

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

17.4

Browser

Mozilla Firefox

Checklist

• [x] I have read and understand the contributing guidelines
• [x] I have checked the existing issues for whether this defect was already reported

[stohrendorf]

Somewhat related to #5583, projects are basically identified by their name and version tuple. As such, you can't have two projects with the same name and version.

[tomkuipers]

Somewhat related to #5583, projects are basically identified by their name and version tuple. As such, you can't have two projects with the same name and version.

Thank you for your response. Is this really the intended behavior? I don't understand the rationale behind it. I tried using parentUUID, but it is not respected either. It also shows up under the wrong parent project with a different UUID. So the combination of project name and version should be unique for the entire dependency-track instance? I did not know that or see the documentation mentioning it. You could potentially overwrite a project of another team, particularly when working with SBOMs of containers from third party providers or vendors. Both teams could be using the same container (and use the project name and version) and overwrite another project they do not manage.