Portfolio Notification: Support for "Summary" Group

[msymons]

Issue Type:

• defect report
• enhancement request

In Dependency Track v3.4.0 there are two types of Portfolio Notification Groups that are related to alerting on new vulnerabilities (ie, ignoring AUDIT Groups):

• NEW_VULNERABILITY
  • 1 component
  • 1 vulnerability
  • 1 or more affected projects
• NEW_VULNERABLE_DEPENDENCY
  • 1 project
  • 1 component
  • 1 or more vulnerabilities

This can result in a LOT of verbosity. To illustrate, creating a new project that uses dropwizard 1.25 results in over 100 notification just relating to vulnerabilities in Jetty and Jackson.

Consequence? A big risk that everyone receiving notifications immediately creates a filter (eg for email) to delete anything sent by Dependency-Track, or a rule to move it to a folder (where stuff still risks getting overlooked because there is so much to wade through).

I think that it might help if DT were to implement a new Notification Group that would allow for sending out a summary email. eg, something like

Project:   Name: Version
New Vulnerable Components:  26
New Vulnerabilities: 108
Increase in Inherited Risk Score:  748

...ideally with a link back to the project.

I use email to illustrate, but I think that this enhancement would also be useful in Slack

[stevespringett]

In its current form, notification are a stream of in-memory events. Once the events have been consumed by any event listeners that care, they are quickly GCed. They are not persistent and reside only in memory.

This enhancement would require storing notification preferences, storage of event summary and details in a time-series data structure so the system could quickly determine what events have occurred since the last time a summary notification occurred for a given user - accounting for permissions and subscription preferences.

There's a lot of complexities here and a lot of overhead required to to fit into the existing architectural pattern. This might make sense to implement post v4.0. As a workaround, it would likely be elementary to consume webhooks external to the system, store then for 24 hours, and send out summaries by reading the the payloads received since the last purge.

[msymons]

@stevespringett, thanks for the feedback. I have created a task to get webhooks tested out per your suggestion.

Would it be just as much work for DT to have a totally new notification which I might call:

VULNERABILITY_FIRST_AFFECT

...which would fire once and once only, on the first time that the portfolio is impacted by a vulnerability? The usage would be to tell the receiver "Here's something that needs triaging that you have never seen before in any project".

At the moment, I have cut back Portfolio alerts to only include NEW_VULNERABILITY and this is still generating a lot of emails. Most are duplicates of stuff that has been seen before. But when the alert is genuinely something new, it sure is hard to tell that it is brand new without a bunch of digging around.

If this is something reasonable, then I'll log a new enhancement issue.

[rkg-mm]

Summary of slack discussion https://owasp.slack.com/archives/C6R3R32H4/p1697795964584119 with @nscuro :
Instead of introducing time series database or logging notifications in a table to send out a summary about it, it makes more sense to introduce a new type of notifications: "Scheduled notifications".
Those notifications don't work on previously stored notifications, but instead work more like a scheduled mini-report, which can re-use the notification template system.

The data about new vulnerabilities & policy violations can be taken from their attribution timestamp. All we need is to store a "last notifications sent out" timestamp per configured scheduled notification.
Additionally, those summaries can be easily enriched with metrics data, which allows to re-use this also for something like a mini-report.

Considering that discussion, lets define some base requirements we should consider, this is my list:

1. Support Templates, re-using notification template system
2. Allow creation of different Scheduled notifications, similar like regular notifications, also with options to limit them to specific projects and define different recipients (e.g. by mail or selected teams).
3. Child-projects shall be includeable in a scheduled notification, too. Ideally different templates could be provided, which either summarize ALL data from all projects in the selection, or split it up per project and list a summary per project within the selection.
4. It shall be stored when the last successful run of the scheduled notification was, and this info shall be used to aggregate data of new vulnerabilities and policies since the last run.
5. Options that could be provided: "NEW_VULNERABILITIES", "NEW_POLICY_VIOLATIONS", "TOTAL_SUMMARY", "TOTAL_DETAILS" the selection affects the data aggregated for the notification and included by the template
6. Different schedules shall be possible. Q: Should there be pre-defined options? Takes flexibility, or how to model ("every X hours", "always at xx:yy each day", "once per day on workdays", "once per week")? Instead a Cron-Like notation (which is not very user friendly)? Other ideas?
7. Is E-Mail enough, or can we instead re-use existing notification publishers to support different channels for sending them out? Is this technically possible?
8. Allow an option to set like "send mails only if new vulnerabilities/violations are identified"

[rkg-mm]

@nscuro my team would take care of this. Is it OK to include https://github.com/jmrozanec/cron-utils into the project for configuring the schedules? That would allow a cron syntax to define the schedules which offers most flexibility. The project seems not updated since 1.5 years though. But this is the most up-to-date library we could find :/. All other options are way older.

[nscuro]

We ended up using https://github.com/asahaf/javacron in Hyades. It doesn't have any dependencies and the code in it is super minimalistic. Most of these libraries are "feature complete", and without any dependency updates there's no reason for maintainers to change anything.

[rkg-mm]

I assume you are using it for something different in Hyades, not for this topic here, right? Just to avoid double work :D

[nscuro]

Correct. It's related, but not duplicated work.

We switched the entire task scheduling over to cron in Hyades, as the previous behavior of "X minutes/hours after start" becomes problematic with multiple API server instances.