Vulnerability identifiers list always triggers security approval
Problem to solve
Some customers have policies that require them to prove they are free of certain classes of vulnerabilities. For instance, a company may commit to their clients that all vulnerabilities related to the OWASP Top 10 weaknesses will be remediated or kept out of production. These customers need a way to turn a specific list of vulnerabilities into an enforceable policy such that these known vulnerabilities cannot be introduced into new code.
Intended users
User experience goal
There are two main components. First, there needs to be an easy way to create and maintain a list of vulnerability identifiers that when detected will trigger a security approval in the MR. This list ideally can be specified globally (at the Instance level) and be inherited by all groups and projects. It can also be specified at the Group or individual Project level; in the former case, it will also cascade down to all child Projects. If set at the Group or Instance level, the inherited list can be overridden at either the Group or Project level. In all cases, it should be clear to the user how specifying or changing a list may affect downstream Groups or Projects.
The second component is an adjustment to the MR security approval. It needs to be clear to a user that their MR triggered a security approval and is blocked from merging because it contained a vulnerability on this pre-defined list (items on the list might be lower severity than would normally trigger a security approval).