Allow user to customize vulnerability-check severity criteria
Effort has been moved to Epic: &6237 (closed)
Problem to solve
Context: we currently have the Vulnerability-Check at the project level. This will disallow a merge request if a Critical, high, or unknown severity vulnerability is detected (regardless of dismissal). Issue part of: &3202 (closed), and follow up to #216588 (closed), which displays whether or not a check is set across projects AND #216590 (closed) which allows user to apply vulnerability-check to multiple projects.
Problem: the vulnerability-check rule has fixed criteria to disallow the merge request: Critical, high, or unknown severity vulnerability is detected (regardless of dismissal). Use case: may only want to disallow with critical vulnerability detected.
Intended users
- Cameron (Compliance Manager)
- Delaney (Development Team Lead)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
- Rachel (Release Manager)
- Alex (Security Operations Engineer)
- Simone (Software Engineer in Test)
- Allison (Application Ops)
User experience goal
Allow users to customize the rule criteria.
Proposal
Allow users to customize the rule severity. Example ability to only disallow merge request if Critical vulnerabilities are detected.
Further details
Issue part of introducing group-level security check: &3202 (closed)
Question and consideration: what are other custom criteria that may be helpful? Such as dismissals of vulns (removing the required approval) or by scanner type? 
Permissions and Security
...
Documentation
Availability & Testing
...
What does success look like, and how can we measure that?
- Can the user select their preferred criteria for the rule?
- Do users adopt the feature across multiple projects, with custom rules?
What is the type of buyer?
Is this a cross-stage feature?
This a cross-stage feature for devopssecure as it is related to the scanning results of all but license scan. Additionally, it will affect the merge request experience, configuration page, and vulnerability management ~"devops::defend"
Links / references
Designs
Relates to
Activity
added UX devopssecure groupcomposition analysis labels
mentioned in epic &3202 (closed)
added to epic &3202 (closed)
cc @NicoleSchwartz per our discussion about customizing
Vulnerability-Checkmentioned in issue #221004
added Enterprise Edition GitLab Ultimate labels
added typefeature label
changed milestone to %Backlog
added [deprecated] Accepting merge requests label
mentioned in issue #221111 (closed)
marked this issue as related to #221111 (closed)
added sectionsec label
- Link to requests:
- Why interested:
- Customer would like the ability to define their own rules as it relates to severities that require approval. According to the documentation, a Vulnerability-Check approval rule blocks MR if critical, unknown or high severity is detected. What if we want to block only critical but allow high, for example.
- Current solution for this problem:
- Not clear if there is a workaround available
- PM to mention: @NicoleSchwartz
Edited by Jefferson Jones
Not clear if there is a workaround available
Not currently, but on a related note, the work we are doing around custom rules within Category:SAST may provide one workaround by overriding the severity of specific rules. This is currently scheduled for %Next 1-3 releases #235359 (closed)
@jeffersonj there is not a work around at this time for that
-
@theoretick when that work around is done could ya'll share with groupcomposition analysis approx how hard that was to implement i'd love to leverage your work if we can
added customer label
marked this issue as related to #235359 (closed)
mentioned in issue #235359 (closed)
removed from epic &3202 (closed)
-
@sam.white @matt_wilson while this is specific to
Vulnerability-Checkseems like it may be related to upcoming protect/policies efforts 
@kmann This is pretty much identical to #221111 (closed). We should probably close one out. I'm happy to close mine as this one has more activity and includes customer requests.
Technically, the security approval/
Vulnerability-checkis part of Threat Insights now. @NicoleSchwartz oversaw this for a long time and I know she has some short-term needs around the approvals that are key to her moving CA forward so happy to keep this where it is.I won't speak for @sam.white but he is overseeing the policy creation. I don't think this would fit under him. I would like to leverage his work though to implement some configurable controls in vulnerability management. The configurable rules here would fit nicely.
@matt_wilson I agree this falls under your purview. As such, I don't have plans to move the Vulnerability Check into the policy management UI; however, I agree it could be a good place for this kind of configuration to live. You could easily leverage the policy UI's IF...THEN... structure to formulate a policy like the following:
IF a merge request contains 1 or more Critical vulnerabilities THEN disallow the merge request (or require approval from xyz person(s))
-
@matt_wilson yup agree you are DRI feel free to close the other and point people here, I keep hoping to be able to grab this but have not yet have time and kinda looking at Q2 right now (sad panda) if @sam.white could get to it sooner i'd be happy to have it grabbed.
@sam.white i was thinking this as my iterative approach pending FE and BE POCs
for project, for approver group, for all scanners, change from default config "critical OR high or unknown" to X where X can be an array ORing together one to all of the levels
next
for project, for approver group, for specific scanners, allow same rules above - i.e. you could treat dast separate than dependencies
next
see how crazy to allow each ruleset to have different approver groups (it's hardcoded today this could be a large change)
obviously subject to change but i think it could fit into an "if this then that" simplified format pretty well, maybe not as complex as you desire, yet (i.e. no 1 or more)
-
Adding related feedback from @vladbudica from prospective customer:
They are interested in customizing the check, by severity, because for them different projects have different importance levels and for the lower ones they don’t want to be as strict as for others. The purpose is to avoid triggering an unnecessary approval that will overload the security team and act as a bottleneck.
added to epic &3953 (closed)
- Link to request: https://gitlab.my.salesforce.com/0064M00000Xc0tN
- Why interested: Security team would like to engage on an MR only when vulnerability is at a certain threshold (High and above)
- Current solution for this problem: N/A
added featureenhancement label
mentioned in issue gitlab-design#1415 (closed)
added groupthreat insights label and removed groupcomposition analysis label
Setting label(s) Category:Vulnerability Management based on groupthreat insights.
added Category:Vulnerability Management label
added UX FY21-Q4 label
added groupsecurity policies label and removed groupthreat insights label
added devopsgovern label and removed devopssecure label
I am closing this issue in favor of work that is starting on this related Epic: &6237 (closed)
marked this issue as related to #204820 (closed)
added SCA:Dependency Scanning label
