# Problem to solve Security teams want to make sure secret push protection is turned on for new all projects. Today, security teams are doing regular checks to make sure secret push protection is enabled for all projects. They are using [update secret_push_protection_enabled](https://docs.gitlab.com/api/group_security_settings/#update-secret_push_protection_enabled-setting) setting via the API for all projects within a group which is time consuming. # Current functionality **This epic will be for new, private** ~"GitLab Ultimate" **projects.** There are the following existing configuration options for SPP: - [Allowing the use of secret push protection in your GitLab instance](https://docs.gitlab.com/user/application_security/secret_detection/secret_push_protection/#allow-the-use-of-secret-push-protection-in-your-gitlab-instance) enables the ability to turn on the feature by an `Admin` - [Enable secret push protection in a project](https://docs.gitlab.com/user/application_security/secret_detection/secret_push_protection/#enable-secret-push-protection-in-a-project) is only at the project level by a `Maintainer` - [Update secret_push_protection_enabled](https://docs.gitlab.com/api/group_security_settings/#update-secret_push_protection_enabled-setting) setting via the API for all projects within a group by a `Maintainer` _Note: Configuration profiles will be applied to projects per _<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/512960/designs/Security_configuration-_vision_-_group_level_-_edit_profile_-_projects.png">_these designs_</a>_._ # Proposal SPP is enabled by default for all new projects; users can deselect this option on project creation if they wish to opt out via the UI and API. # User Experience **For all public projects** ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate", once https://gitlab.com/groups/gitlab-org/-/epics/17502+ is complete SPP will be on by default. If they chose, they can opt out when they create a new project. **For all private** ~"GitLab Ultimate" projects, an `Admin` must [allow the use of secret push protection in a GitLab instance](https://docs.gitlab.com/user/application_security/secret_detection/secret_push_protection/#allow-the-use-of-secret-push-protection-in-your-gitlab-instance). Once they do, users will see the following: ### In the UI When are user creates a blank new project; Enable Secret Push Protection is pre-selected by default. If they chose they can opt out by selecting the check box. {width=1281 height=775} ### Via the API When are user creates a blank new project via the API; Enable Secret Push Protection defaults to `true`. If they chose they can opt out setting the field to \`false\`. ### Audit events When a new project is created there is an audit event that tracks if secret push protection is enabled or not. (TODO: review existing audit events for secret push protection.) #### Why would users want to opt out? Some reasons customers might want to opt-out: * They're already using a 3rd party vendor, like GitGuardian, and they aren't planning to stop using that vendor. They don't want to use two different forms of push protection. * They think our rules generate too many FPs and don't want to allowlist every pattern for every project. * They think the workflow is too intrusive for developers for some projects. * They want to slow roll security features before fully rolling them out organization-wide. ___ # Interlock Details #### Executive Summary This work allows users to opt-in to the ability to enabling secret push protection by for private, Ultimate projects. This will minimize the need for customers to continue to monitor if new projects have secret push protection enabled. #### Engineering Assessment * ~frontend work to add the config options to the new project screen (pending UX review) * ~backend * update the security project setting based on the value of the checkbox * add new audit events #### Dependencies - Team dependencies: - Epic/Issue dependencies - _Link to dependent epics/issues via the linked items widget below for ease of drill down_ - External dependencies: \[Any external dependencies\] - ~"group::security platform management" will need to weigh in as this impacts configuration and the functionality we are proposing may be solved for with configuration profiles. - ~"group::security infrastructure" confirm if infrastructure needs to be involved or not. - ~UX confirm with UX to be sure this is an acceptable user experience. #### DRIs - **PM**: @abellucci - **EM**: @amarpatel - **UX/PDM**: @mfangman - **Group(s)**: ~"group::secret detection" - **Engineering Owner**: @twoodham