### Release notes There is an increasing scrutiny on code changes that can potentially land in production applications and open businesses up to compliance risk and security vulnerability. With scan result policies, you can ensure unilateral changes cannot be made by enforcing two person approval on all merge requests. Scan results policies have a new option to target `Any merge request` which can be paired with defining [role-based approvers](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#require_approval-action-type) to ensure each MR for the defined branches require approval by two (or more) users with a given role (Owner, Maintainer, or Developer). ### Problem to solve As a member of the compliance team, I need to ensure that all merge requests are reviewed by at least one other person who is not also a code author or committer to the merge request so that I can adhere to established compliance standards. ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) ### User experience goal ### Proposal 1. When creating an Approval Policy, users will be able to select `Any merge request` in addition to the `Security scanning` and `License scanning` options currently in the dropdown for the policy Rules. 2. Users may set the policy to enforce conditionally based on `any commits` or only for `unsigned commits`. 3. As part of the merge request approval policy, users will be able to override project settings in the target development projects. All options correlate with the [Merge Request Approval Settings](%20They%20may%20enable/disable%20the%20following%20options%20within%20each%20policy.%20) that are available in each project today and will override those settings. Users may enable/disable the following options within each policy: 1. Prevent approval by merge request's author (Default = true) 2. Prevent approval by anyone who added a commit (Default = true) 3. Remove all approvals when a commit is added (Default = true) 4. Require the user's password to approve (Default = false) 4. As a user hovers over the options listed above, a tooltip overlay will provide more context to the user: 1. **Prevent approval by merge request's author** - When enabled, two person approval is required on all MRs as merge request authors cannot approve their own MRs and merge them unilaterally. 2. **Prevent approval by anyone who added a commit** - When enabled, users who have contributed code to the MR are ineligible for approval, ensuring code committers cannot introduce vulnerabilities and approve code to merge. 3. **Remove all approvals when a commit is added** - If an MR receives all necessary approvals to merge, but then a new commit is added, new approvals are required. This ensures new commits that may include vulnerabilities cannot be introduced. 4. **Require the user's password to approve** - Password confirmation on approvals provides an additional level of security. Enabling this enforces the setting on all projects targeted by this policy. 5. For the project override settings, we will opt for the most secure and compliant option when comparing a policy and a project. If the project does not have this setting toggled on and the policy does, we will enable the setting on the project. If the project has the setting enabled and a security policy targeting the project does not, we will keep the setting enabled on the project. And if multiple security policies are in conflict, where one has the setting enabled, and the other does not, we will enable the setting on the target projects. Essentially, we will opt to enable the settings whenever there is a conflict. We will also default security policies to enable the top 3 settings: 1. Prevent approval by merge request's author (Default = true) 2. Prevent approval by anyone who added a commit (Default = true) 3. Remove all approvals when a commit is added (Default = true) 4. Require the user's password to approve (Default = false) 6. The description above these settings should state the following: 1. `When settings are not enabled in a project, this policy will enable and override project settings for approval rules created by this policy.` 7. As we roll out these changes, newly created policies should include the above defaults, but existing policies would default all settings to `false`, requiring users to update their policies to begin enforcement. ### Designs [Merge request approval policy](https://gitlab.com/gitlab-org/gitlab/-/issues/387048/designs/MR_approval_policy-1-any-mr.png "MR_approval_policy-1-any-mr.png") | New dropdown - "Any merge request" | Override Project Settings Options | |------------------------------------|-----------------------------------| |  |  | | Hover State | 2 Approvals from Maintainer or Developer (existing functionality) | |-------------|-------------------------------------------------------------------| |  |  | | Policy Drawer Details | |-----------------------| |  | ### Further details ### Permissions and Security ### What is the type of buyer? ~"GitLab Ultimate" ### Is this a cross-stage feature? ### Links / references _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->