ignore (suppress) findings globally (system-wide)

[tomaszn]

Description

This change implements a way to ignore security advisories (like CVE, GHSA) globally, system-wide. Vulnerabilities caused by advisories listed in the IGNORED_ADVISORIES environment variable will not be created at all.

Addressed Issue

This fixes #1495, which contains rationale behind this feature.

Additional Details

I solved the issue as simply as I found possible. I treat it more as a workaround for a critical shortage.

Checklist

• 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
• 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
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[valentijnscholten]

How practical is this? Seems like it needs a restart after setting or changing the list of ignored advisories (which ignore vulnerabilities).
Also my feeling is that when vulnerabilities are published, DT will quite quickly have these stored and applied to components. Setting the environment variable after that only prevents future assignment of the vulnerability, but will leave existing assignment behind (I think).

Would it work to have an ignore flag on a vulnerability in DT which can be set/unset via the UI and API. Additionaly an event (and/or scheduled task) that removes ignored vulnerabilities from components?

[nscuro]

There is work underway here to address this feature with a more sustainable solution. Feedback much appreciated.

[tomaszn]

@valentijnscholten, you are right, it has all these downsides. Yet worked for me for several months now.

It is quite practical, because with the deployment configuration versioned, this approach allows documenting and reviewing the changes via merge requests. With a simple switch in the UI widely accessible, beginning users could by mistake ignore the vulnerability globally, instead of suppressing it in the project. It would need a permission.

Maybe the whole suppression feature could be reused, not only for a switch as you suggest, but also for the rest of the analysis inputs. I can imagine that no value in the "project_id" database column would mean a global suppression. Definitely a better solution than mine.

And this use case is also covered by @nscuro's work.