Product discovery for security gates
Problem to solve
Security checks are performed during the pipeline execution, and reports are available in the merge request widget. GitLab is able to determine if new vulnerabilities have been introduced into the code because of the specific changes of the feature branch.
Our security paradigm states that we don't want to make a pipeline fail and block the entire development process if some vulnerability is found. They could be false positive, or just something that is not more important than the development velocity.
On the other side, we're getting a lot of feedback that unsecure code should not be allowed unless previously approved by the security team. This is considered a strict requirement by some customer, and also a must-have by analysts. Security teams don't want to be involved in each and every merge request, but only if security flaws have been found.
We strongly believe that our security paradigm is valid, but we should consider something that allows companies to deal with their compliance requirements and ensure they are able to use GitLab.
Target audience
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
Further details
We recently released multiple approval rules, and we can leverage this feature to build some advanced logic on top of it.
Proposal
This issue is a ~"product discovery" that involves UX, backend, and frontend engineers.
The implementation will be done in https://gitlab.com/gitlab-org/gitlab-ee/issues/9928.
High-level
When new security vulnerabilities are discovered in the merge request, a new approval rule is automatically enabled. The approvers are the members of the security team.
Possible options
The rule may be enabled when even just one new vulnerability is found. Or it can be only if it's with medium severity or higher. Or we can define a threshold formula. Users may want to customize the formula, but in case this should be very simple and with a reasonable default. Conventions over configuration.
The security team should be explicitly selected. So it could actually be any team. In-product suggestions can guide the user to add the relevant people.
The rule may be a generic "conditional approval rule", so in the future other gates can be defined, for example code quality.
What is the type of buyer?
Executive (CISO).