Identify suppressions that are no longer needed.

[mjeffrey]

Description We add a suppression when really needed but at some point the suppression may become unnecessary. For example the dependency is updated (often the issue is hidden in a transitive dependency) or it is identified as a false positive and is no longer needed after a plugin update.

When we do an upgrade of our core dependencies every 3 weeks or an upgrade of the dependency check plugin we manually remove all suppressions and put back the ones we need.

This is to keep our suppression list as small as possible since we need to review them periodically. But this cleaning process is time consuming and error prone.

Suggested Improvement It'd be great to have a flag on the plugin that would report suppressions that are no longer needed. Then we could remove them more easily.

Other Options Considered We considered adding an "until" date to each suppression but we don't want false positives or vulnerabilities that are not applicable to our software to reappear in future. We only use "until" when we really have an issue and want to temporarily suppress to allow builds anyway.

[strangelookingnerd]

Even though I consider the re-evaluation of suppressions from time to time a mandatory step, some sort of automation / reporting would be great! Even if it only consists of logging output by the plugin, this would make maintaining the suppressions so much easier.

+1

[jeremylong]

Simple enough request - a log message when a rule is not used will be included in the next release.

[chadlwilson]

Thanks for doing this - it looks like it would help a lot with maintenance.

I am wondering does someone have this working with the Gradle plugin? I can't seem to see any logs on default Gradle output when using 7.2.1 via dependencyCheckAggregate. Wondering if I am doing something stupid before I try and raise a re-prod case.

[chadlwilson]

I now note https://github.com/jeremylong/DependencyCheck/issues/4840#issuecomment-1245031987 which refers to debug logging and -X for Maven. It seems to work if you enable --debug for Gradle. Unfortunately running a large Gradle build with --debug is IMHO pretty crazy and produces a LOT of output with which these log lines are completely lost. --info also produces a lot of output but might be a bit more manageable. Hmm.

[danielhodder]

It would be awesome if there was a way of getting the rule stats that have been added out as another XML report (or similar). That could then be parsed afterwards to apply whatever logic a particular project needs/wants.

[chadlwilson]

Yeah, I was thinking it would be nice if it were a (collapsed) section on the HTML report as well, alongside "Suppressed vulnerabilties". Probably a separate issue/feature request though - to include these in reports.