Allow compliance teams to prevent pushing and force pushing into protected branches
### Release notes One of several new settings being added to scan result policies, this control will aide in enforcement of security policies and limit the ability to leverage project-level settings to circumvent policies. For each existing or new scan result policy, you can enable `Prevent pushing and force pushing` to take effect for the branches defined within the policy to prevent users from circumventing the merge request flow to push changes directly to a branch. ### Problem to solve Project maintainers can change protected branches to allow code to be force pushed into the branch. This exposes a way for them to circumvent security policies and push code in without going through the normal checks. ### 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) ### Proposal 1. Disallow [pushing to a protected branch](https://docs.gitlab.com/ee/user/project/protected_branches.html#allow-everyone-to-push-directly-to-a-protected-branch) based on the settings enabled in the security policies enforced on the project and branch. 1. Disallow [force pushing to a protected branch](https://docs.gitlab.com/ee/user/project/protected_branches.html#allow-force-push-on-a-protected-branch) based on the settings enabled in the security policies enforced on the project and branch. This would enforce "No One" as allowed to push and merge in each enforced project. 1. Provide an error for developers who attempt to push or force push when a security policy is blocking them. Here's a proposal for the error message: ``` ![remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to `[domain].git`. Force push is blocked by settings overridden by a security policy. ``` Copy: `Force push is blocked by settings overridden by a security policy.` 4. We will add a setting to the existing project settings override options to allow users to opt-in to this feature. For existing policies, we'd default the setting to false, but for all new security policies, we'd default to true. Note: This epic is focused on preventing pushing / force pushing into protected branches. https://gitlab.com/groups/gitlab-org/-/epics/9705+ is related, but focuses on locking the "unprotect" branches settings. ### Design Proposal | Overriding project settings / hover states | Additional project settings | | ------ | ------ | |<img src="/uploads/0dd8c84e580c7d93da51b38857d41395/image.png"> | ![image](/uploads/4d2c90bd08d1d4b0ded1d1d337c16728/image.png) | | For the push and merge setting, we would enforce "No One" as `Allowed to push and merge` | | ------ | | ![image](/uploads/e793c678e2de1b2791faa3e0b9807e9e/image.png) | | | Note: The design does not currently capture the behavior, but for users in a project (any role), they would not be able to modify the push and merge setting. The option would be greyed out and have the same pop-up as other settings in the design - "Security policy overwrites this setting.". #### 3. We would implement error messaging in the terminal when a user attempts a force push (note: we'll want to define and create our own error messaging for this) ![image](/uploads/586214b0f946cb4f75ae59578ad623d7/image.png) ### Permissions and Security ### Documentation ### Availability & Testing ### What does success look like, and how can we measure that? ### 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 -->
epic