Proposal: Support for multiple project parents to enable Environment/Customer tracking

[davidecavestro]

Current Limitation:
Currently, Dependency-Track (DT) supports a strict one-to-many parent-child relationship. While this works for simple hierarchies, it doesn't easily support real-world deployment scenarios where a single software version is shared across multiple environments or customers.

Use-Case:
My goal is to provide an easy way of leveraging DT’s built-in portfolio metrics to answer questions such as: "Which of my customers are currently exposed to this CVE?"

In my current workflow for a microservice-based product, I need to track:

• Project Versions (the microservice artifacts)
• Product Versions (the releases of microservice sets)
• Deployments/Environments (where it's running)
• Customers (who is using it)

To achieve this today, I have to rely on external labeling or duplicate project data. Neither is ideal for maintaining accurate vulnerability metrics across a portfolio.

Minimalist Suggestion:
I suggest evolving the Parent relationship to allow a project version to be associated with multiple parents.

This small change would allow users to create "Logical Projects" to represent a customer or a specific environment.
By linking a Project Version to more than one "Parent" we can naturally represent a 4-tier hierarchy:
Customer → Environment → Product Version → Project Version

Benefits:

• No Data Duplication: One SBOM upload can reflect risk across 10 customers.
• Accurate Risk Assessment: If a microservice is vulnerable, all "Parent" containers (Customers/Envs) correctly inherit that risk status in the dashboard.
• Flexibility: Users can organize their portfolio based on their specific business logic without changing the underlying SBOM format.

I'm curious if the maintainers have considered moving toward a many-to-many association for projects, or if there is a preferred "standard" way to handle this level of deployment tracking?

[Walnussbaer]

Would appreciate this feature as well. We want to track our microservices based releases on dtrack. Currently, If a release does not provide a new version for every microservice, the new release only contains the services with changed versions. For all other services that did not change their version, the SBOMs on the old release (old parent) are just updated. In other words, I would realy like to attach a project to multiple parents.

EDIT: I think this is a duplicate of #4953

[davidecavestro]

Thanks for pointing out the possible duplicate - I definitely missed it!
I had already commented on a couple of issues, such as #869 and #3375, but I felt the need to clearly state here what I think could be a valid use case for DT.

[Passarinho4]

I’d love to see this move forward! Using tags as a workaround hasn't been ideal for our workflow. Do you know what the path to implementation looks like? Let me know if there's anything that needs to be reviewed first or if we're just waiting on the MR.

[nscuro]

Allowing multiple parents has a lot of implications that are not trivial to work around. This mostly affects features that traverse project hierarchies "downwards", logically speaking. For example:

• The "Notify children" feature for alerts. The selling point here is that you should be able to configure an alert for a project or set of projects once, and have it automatically apply to all of their children.
• Policies have a similar feature where they can be limited to a set of projects, and optionally all their children.
• The portfolio ACL feature is used to limit access to projects based on team membership. Access is expected to be inherited by children (Respect hierarchy in ACL definitions #2042). If a project can have multiple parents, this would risk teams gaining access to projects they shouldn't have access to.

In general, the project model would need to evolve from being a simple tree, to becoming a full DAG. This further impacts metrics aggregation, requires cycle detection, and complicates all call sites that interact with project hierarchies.

The current tree model has the benefit of being very simple, and it allows for efficient query patterns using closure tables.

That being said, there is related, similarly complicated work that I'd like to tackle eventually, namely decoupling the concept of project from project versions. So we are very much open to reworking the current model, but it will very likely necessitate breaking changes in terms of API surface and behaviour.

[davidecavestro]

I found this valuable explanation very insightful: it further convinced me that Dependency-Track's core is well managed, with a focus on stability.

Honestly, I don't consider this a flaw, but rather a strength.

To me, this means additional risky or agile features should be provided by external layers built on the provided foundations. In other words, outside projects should fill the gaps.

This leaves room for many possibilities. The core (DT) provides persistence with a stable API. Additional features, such as DAG, can be implemented externally and may eventually be provided by the core.