Add option to configure notifications based on severity level #4879

emyhrberg · Apr 25, 2025

Description

This PR adds support for configuring which CVE severities should trigger alert notifications.

Previously:

All NEW_VULNERABILITY_IDENTIFIED events triggered notifications, regardless of severity (e.g., low, medium, high).

Now:

Users can select which severities (e.g., only CRITICAL and HIGH) should trigger notifications. This helps reduce noise and makes it easier to focus on the most important vulnerabilities.

If no severity is selected, the system behaves as before (all severities trigger alerts).

Addressed Issue

Closes #3767

Additional Details

As mentioned by users in the issue, teams managing many microservices currently receive too many alerts for low-priority issues. This change allows them to only receive notifications for critical or high-severity vulnerabilities, reducing email overload and improving focus.

Screenshot

Also, see frontend PR

Checklist

I have read and understand the contributing guidelines
This PR introduces new or alters existing behavior, and I have updated the documentation accordingly
This PR implements an enhancement, and I have provided tests to verify that it works as intended
~~- [] This PR fixes a defect, and I have provided tests to verify that the fix is effective~~
~~- [] This PR introduces changes to the database model, and I have added corresponding update logic~~

owasp-dt-bot · Apr 25, 2025

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

codacy-production · Apr 25, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.01% (target: -1.00%)	✅ 89.66% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (`31eefe0`)	24029	19363	80.58%
Head commit (`271d118`)	24057 (+28)	19388 (+25)	80.59% (+0.01%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4879)	29	26	89.66%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings Change summary preferences

rkg-mm · Apr 25, 2025

Love this, I need this :)
Not sure if maintaining them as string is the best solution, but will leave this up to maintainers ;)

But another note: I might have overseen something, but what happens if you already have notification rules and then install this update? Did I miss some migration or default that falls back to the original behavior for already existing rules?

emyhrberg · Apr 27, 2025

Love this, I need this :) Not sure if maintaining them as string is the best solution, but will leave this up to maintainers ;)

But another note: I might have overseen something, but what happens if you already have notification rules and then install this update? Did I miss some migration or default that falls back to the original behavior for already existing rules?

Hi @rkg-mm

Thanks alot! 😄
About your question: existing notification rules will continue work exactly as before. This means if notifySeverities is not set, it will default to all severities. Only Mail notifications (SendMailPublisher) are filtered, and they are only filtered for the event types selected (which work exactly as before).

Also, regarding storing severities as a comma-separated string: It is consistent with how notifyOn was already stored, but we can change this if needed.

src/main/java/org/dependencytrack/notification/NotificationRouter.java

Signed-off-by: Erik Myhrberg <erimy268@student.liu.se>

emyhrberg · May 4, 2025

I believe this PR is ready to merge @nscuro

nscuro · May 13, 2025

src/main/java/org/dependencytrack/model/NotificationRule.java

+                result.add(Severity.valueOf(s.trim()));
+            }
+        } else {
+            return List.of(Severity.values());


The problem with returning all severities per default is that this also "bleeds" through to the REST API. We'd then have NotificationRules returning all severities, even if they are not configured for vulnerability-related NotificationGroups.

Perhaps this kind of fallback should be in NotificationRouter instead, when notifivySeverities is actually being evaluated?

The reason we implemented it by returning all severities per default is to have it visually check all the checkboxes by default. I figured this would clarify the behaviour of the options to the users. Anyway, I moved the empty list check to NotificationRouter, as you suggested, and it still works as expected. Only the visual part changed; all the checkboxes are not checked by default. But we are open to change it, if needed.

nscuro · May 13, 2025

src/main/java/org/dependencytrack/notification/publisher/Publisher.java

+    default void inform(PublishContext ctx,
+                        Notification notification,
+                        JsonObject config,
+                        List<Severity> notifySeverities) {
+
+        if (notification == null || config == null) {
+            return;
+        }
+
+        // Filter out unwanted notifications based on the configured severities
+        if (notifySeverities != null && !notifySeverities.isEmpty()
+            && notification.getSubject() instanceof NewVulnerabilityIdentified vuln) {
+
+            final Severity sev = vuln.getVulnerability().getSeverity();
+            if (sev != null && !notifySeverities.contains(sev)) {
+                return;
+            }
+        }
+
+        // Call the default inform method
+        inform(ctx, notification, config);
+    }


Consider performing the filtering here in NotificationRouter instead.

Notifications not eligible for publishing should never reach the Publisher to begin with.

Fixed, moved the filtering to where you suggested in NotificationRouter, where I also added filtering to NewVulnerableDependency.

nscuro · May 13, 2025

src/main/java/org/dependencytrack/model/NotificationRule.java

+        if (notifySeverities.isEmpty()){
+            this.notifySeverities = null;
+            return;
+        }
+        StringBuilder sb = new StringBuilder();
+        for (int i=0; i<notifySeverities.size(); i++) {
+            sb.append(notifySeverities.get(i));
+            if (i+1 < notifySeverities.size()) {
+                sb.append(",");
+            }
+        }
+        this.notifySeverities = sb.toString();


Suggested change

if (notifySeverities.isEmpty()){

this.notifySeverities = null;

return;

}

StringBuilder sb = new StringBuilder();

for (int i=0; i<notifySeverities.size(); i++) {

sb.append(notifySeverities.get(i));

if (i+1 < notifySeverities.size()) {

sb.append(",");

}

}

this.notifySeverities = sb.toString();

if (notifySeverities == null || notifySeverities.isEmpty()){

this.notifySeverities = null;

return;

}

this.notifySeverities = notifySeverities.stream().collect(Collectors.joining(",");

nscuro · May 13, 2025

src/main/java/org/dependencytrack/notification/publisher/Publisher.java

+        if (notifySeverities != null && !notifySeverities.isEmpty()
+            && notification.getSubject() instanceof NewVulnerabilityIdentified vuln) {


Shouldn't this also apply to NEW_VULNERABLE_DEPENDENCY notifications? In that case, a component can have multiple vulnerabilities. How do we want to treat that case? Do we drop the entire notification, or do we just filter out vulnerabilities that don't fit the configured severity criteria?

Added filtering for NEW_VULNERABLE_DEPENDENCY notifications.

It currently works by dropping the entire notification if it does not fit the configured severity filters.

emyhrberg · May 14, 2025

A new commit has been made addressing the comments from @nscuro .

- Move severity filtering code, so it doesn't reach the publisher - Remove some unnecessary publisher tests - Add new tests in NotificationRouterTest, SendMailPublisherTest and SlackPublisherTest Signed-off-by: Erik Myhrberg <erimy268@student.liu.se>

emyhrberg force-pushed the issue-5-severity-v2 branch from b76291a to 99b53de Compare April 25, 2025 09:30

emyhrberg marked this pull request as ready for review April 25, 2025 09:39

emyhrberg closed this Apr 27, 2025

emyhrberg force-pushed the issue-5-severity-v2 branch from 0435a09 to 31eefe0 Compare April 27, 2025 21:29

emyhrberg deleted the issue-5-severity-v2 branch April 27, 2025 21:51

emyhrberg restored the issue-5-severity-v2 branch April 27, 2025 21:52

emyhrberg reopened this Apr 28, 2025

emyhrberg force-pushed the issue-5-severity-v2 branch 5 times, most recently from 9def475 to d0aab3d Compare April 29, 2025 11:36

nscuro reviewed Apr 29, 2025

View reviewed changes

src/main/java/org/dependencytrack/notification/NotificationRouter.java Outdated Show resolved Hide resolved

emyhrberg force-pushed the issue-5-severity-v2 branch 13 times, most recently from 3550f14 to 1d35800 Compare April 29, 2025 16:46

emyhrberg force-pushed the issue-5-severity-v2 branch 5 times, most recently from dd849a2 to 6527935 Compare April 29, 2025 17:35

Add notification severity options

42e89ab

Signed-off-by: Erik Myhrberg <erimy268@student.liu.se>

emyhrberg force-pushed the issue-5-severity-v2 branch from 6527935 to 42e89ab Compare April 29, 2025 17:42

Add tests for severities for most publishers

271d118

Signed-off-by: Erik Myhrberg <erimy268@student.liu.se>

emyhrberg changed the title ~~Add mail notification severity options~~ Add option to configure notifications based on severity level Apr 30, 2025

nscuro requested changes May 13, 2025

View reviewed changes

emyhrberg force-pushed the issue-5-severity-v2 branch 2 times, most recently from 466c4c6 to 31c1d65 Compare May 14, 2025 17:32

emyhrberg force-pushed the issue-5-severity-v2 branch from 31c1d65 to 516e5b6 Compare May 14, 2025 17:36

emyhrberg requested a review from nscuro May 14, 2025 18:26

emyhrberg force-pushed the issue-5-severity-v2 branch from 516e5b6 to d779af1 Compare May 14, 2025 18:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Add option to configure notifications based on severity level #4879

Add option to configure notifications based on severity level #4879

Uh oh!

emyhrberg commented Apr 25, 2025 •

edited

Loading

Uh oh!

owasp-dt-bot commented Apr 25, 2025 •

edited

Loading

Uh oh!

codacy-production bot commented Apr 25, 2025 •

edited

Loading

Uh oh!

rkg-mm commented Apr 25, 2025

Uh oh!

emyhrberg commented Apr 27, 2025

Uh oh!

Uh oh!

emyhrberg commented May 4, 2025

Uh oh!

nscuro May 13, 2025

Uh oh!

emyhrberg May 14, 2025

Uh oh!

nscuro May 13, 2025

Uh oh!

emyhrberg May 14, 2025

Uh oh!

nscuro May 13, 2025

Uh oh!

emyhrberg May 14, 2025

Uh oh!

nscuro May 13, 2025

Uh oh!

emyhrberg May 14, 2025

Uh oh!

emyhrberg commented May 14, 2025

Uh oh!

Uh oh!

		if (notifySeverities != null && !notifySeverities.isEmpty()
		&& notification.getSubject() instanceof NewVulnerabilityIdentified vuln) {

Search code, repositories, users, issues, pull requests...

Uh oh!

Add option to configure notifications based on severity level #4879

Are you sure you want to change the base?

Add option to configure notifications based on severity level #4879

Uh oh!

Conversation

emyhrberg commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Previously:

Now:

Addressed Issue

Additional Details

Screenshot

Checklist

Uh oh!

owasp-dt-bot commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🎉 Snyk checks have passed. No issues have been found so far.

Uh oh!

codacy-production bot commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage summary from Codacy

Uh oh!

rkg-mm commented Apr 25, 2025

Uh oh!

emyhrberg commented Apr 27, 2025

Uh oh!

Uh oh!

emyhrberg commented May 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emyhrberg commented May 14, 2025

Uh oh!

Uh oh!

emyhrberg commented Apr 25, 2025 •

edited

Loading

owasp-dt-bot commented Apr 25, 2025 •

edited

Loading

codacy-production bot commented Apr 25, 2025 •

edited

Loading