### Release notes Security policies enforce scanners to run in GitLab projects, as well as enforce MR checks/approvals to ensure security and compliance. With branch exceptions, you can more granularly enforce policies and exclude enforcement for any given branch that is out of scope. Should a developer create a development or test branch that is unintentionally affected by heavy-handed enforcement, they can work with security teams to exempt the branch within the security policy. ### 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. This problem is intended to be solved by https://gitlab.com/groups/gitlab-org/-/epics/9705+; however, before we can do that work, we first need to make sure that there is a way for users to unprotect a branch if branch protection was applied by accident. By allowing security teams to define exceptions to their policies, we make 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. As part of a scan execution or scan result policy, users will be able to specify branch exceptions as part of their yaml file. This will give users a way to override or not apply a policy to a branch that was marked as protected by accident. Branch exceptions will be defined as an object to enable users to specify the branch name and associated project. Alternatively, a user may specify only the branch name and all branches matching the name will be exempted. 2. We'd want to prepare to also support exceptions at the group level, as there are plans to support branch settings at that level in https://gitlab.com/groups/gitlab-org/-/epics/8679#note_1348611764. Example: ```yaml scan_execution_policy: - name: Test enabled: true rules: - type: pipeline branch_type: all || protected || default branches: - main - master branch_exceptions: - master - rc # when supplying a name "rc", any branches matching rc will be excluded - { name: 'develop', full_path: 'my-group/project' } # name and full_path must be present in objects - { name: 'develop', full_path: 'my-group' } # create exceptions for branches at the group level ``` ### Design Proposal [](https://gitlab.com/gitlab-org/gitlab/-/issues/387048/designs/Security_policy-2-exceptions.png "Security_policy-2-exceptions.png") [](https://gitlab.com/gitlab-org/gitlab/-/issues/387048/designs/More_dropdowns.png "More_dropdowns.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 <!-- 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 -->