BOM upload via projectName/parentName ignores parent scope, causing cross-namespace project collisions (regression impact after 4.14.2 → 5.0.2 upgrade)

[sh4ntanu321]

Current Behavior

We upload SBOMs via POST /api/v1/bom using projectName + projectVersion + parentName (not UUID-based project/parent), e.g.:

curl -X POST "$BOM_URL/api/v1/bom" -H "X-Api-Key: $BOM_UPLOAD_TOKEN" \
  -F "autoCreate=true" \
  -F "projectName=$CI_PROJECT_NAME-codebase" \
  -F "projectVersion=$CI_COMMIT_BRANCH" \
  -F "parentName=$CI_PROJECT_NAMESPACE" \
  -F "isLatest=true" \
  -F "bom=@cyclonedx-codebase.json"

This worked correctly on 4.14.2. After upgrading to 5.0.2, when a project with the same projectName + projectVersion already exists under a different parent namespace, the BOM is imported into that unrelated existing project instead of being created under (or matched against) the parentName we explicitly specified.

We have 200+ CI/CD pipelines already configured against this API contract (projectName + projectVersion + parentName), so switching every pipeline to UUID-based project/parent referencing is not a feasible short-term fix for us.

Steps to Reproduce

1. Create Project A: projectName=service-x, projectVersion=main, parentName=team-alpha (via autoCreate=true on BOM upload).
2. Create Project B: projectName=service-x, projectVersion=main, parentName=team-beta (via autoCreate=true on BOM upload).
3. Re-upload a BOM for projectName=service-x, projectVersion=main, parentName=team-beta.
4. Observe: the BOM is imported into whichever project matched first by name+version, not necessarily the one under team-beta.

Expected Behavior

parentName should be honored as part of the project lookup/match key. Two projects with identical projectName + projectVersion but different parentName should be treated as distinct projects, each scoped to their own parent — not merged/matched across namespaces. This matches the expected behavior already described in #5586.

Environment

• Dependency-Track version: 5.0.2 (previously working correctly on 4.14.2)
• Database PostgreSQL 18
• Deployed in Kubernetes
• Upload method: POST /api/v1/bom, multipart form, autoCreate=true, isLatest=true
• Scale: ~200+ CI/CD pipelines relying on name/version/parentName-based resolution (not UUID-based)

Impact

This causes SBOMs to be silently uploaded into the wrong project/namespace whenever a name+version collision exists across different parents in the portfolio — with no error or warning, making it hard to detect until someone notices vulnerability data appearing under the wrong team/parent. Given the scale of existing pipeline configurations, a UUID-based workaround is impractical for us in the near term, and we suspect other users relying on name-based resolution across large multi-team portfolios face the same risk.

Suggested Fix

Include parentName (and parentVersion, if provided) as part of the project resolution key in the BOM upload endpoint, so lookups/auto-create are scoped within the specified parent rather than matching globally on projectName + projectVersion alone.

Dependency-Track Version

5.x

Browser

N/A

Checklist

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

[nscuro]

This should have never worked, and looking at the code in v4, it never did. The issue you linked was raised against v4 as well. The parent never influenced a project's identity.

FWIW this is also explicitly mentioned in the v5 docs: https://dependencytrack.github.io/docs/next/concepts/projects/#hierarchies

The hierarchy does not affect identity. A name and version pair remains globally unique, so the same combination cannot appear under two different parents.

[sh4ntanu321]

This should have never worked, and looking at the code in v4, it never did. The issue you linked was raised against v4 as well. The parent never influenced a project's identity.

Hi @nscuro,

Thank you for your reply and support.

Yes, we also observed that the same issue exists in the 4.14.x release. When uploading a BOM using projectName and parentName, it appears to overwrite another project instead of associating the BOM with the intended child project.

If the BOM upload API is not intended to group or identify projects based on parentName, could you clarify the intended use case of the parentName parameter during a cURL BOM upload? From the API, it seems that parentName should help uniquely identify the target project under a specific parent, but the current behavior suggests otherwise.