Team Recipients for Notifications (email + ACL scope)

[ch8matt]

Current Behavior

Notification rules currently target publishers with static destinations (email address). When a portfolio-scoped event occurs (such as a policy violation), Dependency-Track generates a notification containing the impacted project based on the rule’s project/tag filters, but it does not apply the recipient team’s ACL to that notification payload.

As a result, a team can receive policy notification emails that reference projects outside of its ACL scope, including projects owned by another team.

Steps to Reproduce

1. Create two teams

   • Team A
   • Team B

2. Create two projects

   • Project A
   • Project B

3. Configure ACLs so teams are isolated

   • Grant Team A access only to Project A.
   • Grant Team B access only to Project B.

4. Create a policy that will be violated

   • Make sure this policy applies to all projects

5. Create a Notification Rule for policy violations

   • Scope: PORTFOLIO
   • Notify on: Policy Violation
   • Publisher: EmailPublisher
   • Destination: email address for Team A
   • limit the rule to projects Project A and Project B

6. Trigger a policy violation on Project B

   • Upload a BOM to Project B containing a component that violates the policy.
   • Wait for BOM processing to complete and the violation to be detected.

7. Observe the notification email

   • The email sent to Team A includes Project B (and related violation details), even though Team A has no ACL access to Project B.

Expected Behavior

When a notification rule triggers, Dependency-Track should deliver notifications that respect organizational access boundaries:

• Recipient-aware filtering of projects:
  Before sending, Dependency-Track should filter the notification payload to keep only projects the recipient is allowed to see. For a team recipient, this means:
  Notification.projects = affected projects ∩ team.allowedProjects.

• No cross-team notifications:
  A team must never receive a policy notification referencing projects outside its ACL scope, even if the underlying policy/rule matched those projects globally.

• Skip notifications with no visible projects:
  If filtering leaves zero projects, the notification should not be sent to that team.

Proposed fix

Instead of configuring a static destination email in the notification rule, the rule should allow selecting a Team as the recipient. Dependency-Track would then:

1. Resolve the destination from the Team
   Use the Team’s configured email automatically, removing the need to hardcode an email address in the rule.

2. Apply the Team’s ACL to the notification payload
   Filter Notification.projects using the Team’s allowedProjects before rendering and publishing.

This makes notifications correct by design: the recipient identity (Team) carries both the destination and the authorized scope, so notifications cannot leak projects across teams and configuration remains centralized in one place.

Dependency-Track Version

4.13.6

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

No response

Browser

Google Chrome

Checklist

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

[ch8matt]

@nscuro Hello, is this something being worked on for Hyades ?

Have a great day

[nscuro]

@ch8matt This is not something we've been actively working on yet, but I feel like this should build upon the general ACL improvements we've made in hyades.

The primary limitation of ACL-related features in v4 is that project hierarchies cannot be considered in a way that performs well. In hyades we have drastically improved this: https://github.com/DependencyTrack/hyades/blob/main/docs/architecture/decisions/005-materialize-project-hierarchies.md.