Expiration support for vulnerability suppressions

[masse-solita]

Current Behavior

Currently vulnerabilities can be suppressed but no expiration can be set like in OWASP Dependency-Check.

Proposed Behavior

Setting a suppression date would be helpful in cases where:

• A patch for a vulnerability doesn't exist yet
• The vulnerability might not be currently be relevant but worth re-checking in the future

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[arjavdongaonkar]

I can think following to implement the suppression expiration feature:

1. Date Picker on Suppression: Provide a date picker UI when suppressing a finding, allowing users to set a suppression expiration date.
2. Re-evaluation on Detection: When the same finding is detected again, check if it's currently suppressed. If so, verify whether the current date has passed the expiration date. If it has, automatically unsuppress the finding.
3. Audit Logging: Log all suppression and unsuppression events for traceability.
4. Scheduled Unsuppression: (Optional) Add a daily scheduler to evaluate and update suppressed findings that have passed their expiration, marking them as unsuppressed.

Any suggestions are welcomed

Started work. Will try to continue on this next week

• Backend PR: dependency-track#5002
• Frontend PR: frontend#1262

[nscuro]

This might be a bit more nuanced:

• If the finding is currently suppressed with a date and a client switches it back from suppressed to unsuppressed, the date should be removed.
• Do we really only want this to apply to suppressions, or to the analysis as a whole? Usually when you suppress something, you mark it as FALSE_POSITIVE or similar as well. Wouldn't we want to reset that, too?
• If the above is true, then we need a means to store the previous values of the fields we want to reset.

[arjavdongaonkar]

Hi nscuro,

1. Manual unsuppression: Agreed, will remove expiration date when user manually unsuppresses.
2. Analysis changes: Not very sure about resetting the finding analysis. Even now, when a finding is manually suppressed or unsuppressed, we do not change the analysis value.

But yes, please let me know if we want to proceed with resetting the analysis after expiration. Will make the required changes.

[arjavdongaonkar]

How about default suppression expiration ?

Right now, suppressions remain until explicitly removed or until the optional expiration date is set. It might be useful to have a configurable default expiration (e.g., 30/60/90 days), applied automatically when a user suppresses a finding but doesn’t set a date. This will

• Prevents suppressions from staying around indefinitely by mistake.
• Ensures findings resurface for re-evaluation if they remain relevant.

Questions:

1. Should this default be global (system-wide), or configurable per project?
2. Should users have the option to override the default and set “no expiration”? @nscuro Any views here?