### Walkthrough :tv: https://youtu.be/CkCiHR-OWC8 ### Why is this important? Policies create the guardrails for how businesses operate and these compliance requirements are typically associated with some business risk. An organization may have a SOC2 requirement to ensure multiple reviewers review any changes that impact production (this is very common). In other cases, our policies help enforce security programs by enforcing security scanners to run, identify vulnerabilities before they are introduced, and address or mitigate them. However, security is about more than encouraging the right behavior, we also must ensure compliance of the rules we’ve defined. The changes in this epic help our customers address key security and compliance requirements, as well as ensure there are no opportunities to circumvent the defined policies. ### Problem 1 - Introduce the ability to enforce 2 person approval on all merge requests (on default branch or protected branches) One of the most common compliance requirements raised by our customers is desire to require two-person approvals on all merge requests that impact production. This ensures there is no way for a single person to unilaterally introduce a vulnerability through a merge request and also merge the change, resulting in immediate risk to production environments. ### Problem 2 - Circumvention of Security Policies Currently there are several ways that project maintainers can circumvent security policies. - **Renaming branches:** If a policy is set to enforce only on the main branch, maintainers of projects inheriting the policy may change their branch name to master to circumvent the policy enforcement. - **Unprotecting branches:** Project maintainers are currently able to modify branch protection settings. In a case where they feel it's important to merge code regardless of security policy, they could temporarily unprotect their default branch, allow code to merge, then reset branch protection. However, for compliance, this becomes an unaudited circumvention of the policy. - **Force pushing to protected branches:** Projects owners/maintainers can also choose to allow or block force pushes to protected branches. Similar to unprotecting branches to circumvent policy, this could also allow code to skip code review and directly push changes that may include vulnerabilities. - **Pushing to protected branches:** Similar to the option above, owners/maintainers can choose to allow or block users from pushing and merging to protected branches. This would also allow developers to avoid the merge request flow and peer review. - **Modifying MR approval rules:** At the project level, project owners/maintainers can prevent approval by author, prevent approval by any users who adds commits, prevent editing approval rules, and require user password to approve. To maintain compliance across a GitLab instance or namespace, however, there is no control preventing project maintainers from modifying these settings. A maintainer could temporarily allow approval by author and circumvent peer review to push code themselves without requiring approval. Generally speaking, most users who use such workarounds may have good intentions, but it does break compliance and exposes our customers and their businesses to risk. By addressing these gaps in our policy management, we can ensure there's an audit trail and that changes to production code aren't merged without necessary checks and balances. ### Problem 3 - Refresh the policy type name of Scan Result Policy to Merge Request Approval Policy As we expand the scope of this policy type to take actions against any merge requests, not only based on the results of security scanners, we are updating the policy type name to Merge Request Approval Policy. This epic holds a collection of proposals to close these gaps and allow compliance teams to fully rely on security policies. _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._ ### Design ##### UX Theme: https://gitlab.com/gitlab-org/gitlab/-/issues/387048/ **MR approval policy (Old name: Scan result policy)** | Target `Any merge request` example | `Exception` dropdown example | More dropdown example | |------------------------------------|------------------------------|-----------------------| | | ! |  | | `Protected branch` example | After user select protected branch, show popover for overwritten settings| When policy enabled, how it looks on protected branches settings | When policy enabled, how it looks on mr settings | |----------------------------|----------------------------------------------|------------------------------------------------------------------|--------------------------------------------------| ||  |  |  | | Detailed view of settings override | |------------------------------------| || ### Solution Validation Two solution validations were completed to validate the user flows within this epic, as well as the name change from `Scan Result Policy` to `Merge Request Approval Policy`. 1. https://gitlab.com/gitlab-org/ux-research/-/issues/2416+ 2. https://gitlab.com/gitlab-org/ux-research/-/issues/2380+ ### Business Objectives and Customer Impact Customers want assurance policies are being enforced and that compliance requirements are properly met. We have several customers up for renewal and potential uptier to Ultimate soon and this is a pain point. We also have internal compliance requirements that will be satisfied by these plans. - https://gitlab.my.salesforce.com/0016100001HGQEj Large, Premium (Ultimate prospect) - https://gitlab.my.salesforce.com/0016100001ZPiiCAAT - https://gitlab.my.salesforce.com/0016100001FT0bdAAD - https://gitlab.my.salesforce.com/00161000015M5IEAA0 - https://gitlab.com/groups/gitlab-com/Finance-Division/itgc-compliance-gitlab.com/-/epics/15 ~Dogfooding for ITGC Compliance <!-- 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 -->