[Feature] Vulnerability update notifications

[4naesthetic]

Description

Adds support for sending notifications when the severity of an existing vulnerability associated with a project is updated.

Addressed Issue

Addresses: #2361 Supersedes: #2730

Additional Details

This PR builds on the previous work done in #2730 by @Ehoky (thank you for your work!).

The main difference is that the quantity of notifications has been reduced. Instead of generating a separate notification for every affected component associated with an updated vulnerability we only generate one. The previous implementation generated a notification for every instance of a component, even if they represented the same logical software package, which means that if the same vulnerable component was used across 200 projects then 200 notifications would be generated instead of one.

Other differences include:

• No longer reporting on affected projects to prevent huge notification bodies, and only including a single component entry in the notification
• Adding vuln source, vuln ID and aliases to the vulnerability notification subject JSON payload
• Correctly emitting events from the AbstractNistMirrorTask that doesn't use the VulnerabilityQueryManager::updateVulnerability method

To support the 'Limit To Projects' functionality we still need to read all affected components (and their associated project IDs) before dispatching the notification even though they don't appear in the payload, so there is still some potential for scalability issues.

Checklist

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

[codacy-production[bot]]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
:white_check_mark: +0.08% (target: -1.00%)	:white_check_mark: 86.67% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (2812b3a0873627b383b2e153f1e476cf7c3bd800)	22107	16894	76.42%
Head commit (a63290dc10be6ea9b0a673c714d985afa33a7cdb)	22233 (+126)	17008 (+114)	76.50% (+0.08%)

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 (#4067)	120	104	86.67%

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

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[4naesthetic]

Hmm... one of the new tests is failing in CI but passing locally which I'm having trouble replicating (NotificationUtilTest.testVulnerabilityUpdateMultipleComponents). Any ideas?

[nscuro]

Notifications are dispatched and processed asynchronously, so tests asserting on them can suffer from race conditions. I would recommend to use Awaitility to account for that, see here for an example: https://github.com/DependencyTrack/dependency-track/blob/b4ac9cd50a71db76128977de858c09af4091f282/src/test/java/org/dependencytrack/tasks/BomUploadProcessingTaskTest.java#L1298-L1302

[4naesthetic]

Notifications are dispatched and processed asynchronously, so tests asserting on them can suffer from race conditions. I would recommend to use Awaitility to account for that, see here for an example:

https://github.com/DependencyTrack/dependency-track/blob/b4ac9cd50a71db76128977de858c09af4091f282/src/test/java/org/dependencytrack/tasks/BomUploadProcessingTaskTest.java#L1298-L1302

Thanks for that. I've updated the asynchronous tests to use Awaitility so hopefully that should eliminate any race conditions.

Edit: Actually the conditions for the failing test still aren't quite correct. Will update again shortly.

Edit2: Ready to go now.

[4naesthetic]

Frontend PR: https://github.com/DependencyTrack/frontend/pull/974

I think this is ready for review. Any chance of this making it into the 4.12 release?

[nscuro]

I think this is ready for review. Any chance of this making it into the 4.12 release?

I'll try to get it reviewed this week. Unless there are some major issues I don't see why it wouldn't make it to v4.12.

[codacy-production[bot]]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
:white_check_mark: +0.40% (target: -1.00%)	:white_check_mark: 86.44% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (2812b3a0873627b383b2e153f1e476cf7c3bd800)	22107	16894	76.42%
Head commit (1cb7273eab7ac1e7da9b602e48ad0a78169ac0d3)	22367 (+260)	17182 (+288)	76.82% (+0.40%)

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 (#4067)	118	102	86.44%

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

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}