### Release notes One of several new settings being added to scan result policies, branch modification controls will ensure 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 branch modification` to take effect for the branches defined within the policy to prevent users from deleting or unprotecting those branches. ### Problem to solve Project maintainers can unprotect branches, rename branches, and change the default branch. This exposes a way for them to circumvent security policies and push code in without going through the normal checks. ### Prerequisites - Give users the ability to [choose between Default branch, All Protected Branches, and Specific Protected Branches when defining policies](https://gitlab.com/groups/gitlab-org/-/epics/9567). This ensures policies are applied to all default branches, regardless of the branch name (which could allow teams to circumvent policies). - Ensure there is a way for users to unprotect a branch if branch protection was applied by accident - Allow security teams [to define exceptions to their policies](https://gitlab.com/groups/gitlab-org/-/epics/9567). This makes it possible for a security policy to not apply to a specific branch so that it can then be unprotected by the project maintainers. ### 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. When creating a new scan result policy (or editing an existing scan result policy), they will have a new toggle option available under `Override project approval settings`: "Prevent branch protection modification". We discussed enforcing this implicitly, but it doesn't give organizations flexibility in opting in, and would require more communication. See https://gitlab.com/groups/gitlab-org/-/epics/10831#note_1429662398. 1. 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. 1. When users visit their merge request approval settings (within project settings), the option to unprotect a branch will be greyed out and cannot be toggled. On hover, they will receive a warning in a popup that provides context and guides them to unprotect the branch if it's allowed. 1. Warning/info messages will direct users to our documentation that we'll need to create, that will guide developers and security/compliance professionals in adding the branch as an exception to their policy, allowing project maintainers to then unprotect the branch (with their approval). 1. When any policies are in conflict, default to the most secure and compliant configuration. For example, if a group enforces branch protection in group level settings and a policy does not enforce this rule, we will default to use the group-level setting. If a group policy overrides the ability to unprotect branches and a project level policy does not, we accept the group policy. If a project level policy prevents deletion of protected branches and a group level policy does not, we accept the project level policy. 1. When the rule above does not suffice, settings enforced in policies at the project level take precedence over anything defined at the group level. 1. When policy is applied on group-level and protected branch configured on group-level is mentioned in the policy, this group-level policy should not be modifiable. Note: This epic is focused on unprotecting branches. https://gitlab.com/groups/gitlab-org/-/epics/9706+ is related, but focuses on preventing pushes and force pushes. ### Design Proposal [:art: Warnings on protected branch and force push settings in project settings](https://gitlab.com/gitlab-org/gitlab/-/issues/387048/designs/Protected_branch.png) | Project override settings in Security Policy creation | Hover states in projects that have been overridden by a policy | | ------ | ------ | | | | ### 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 -->