[[_TOC_]] ## Problem Today, secret detection configuration is more complex than it needs to be and also not as flexible as it should be. Some things that could be improved: * Pipeline-based SD requires editing a YAML file * Push protection does not allow for custom rules * Pipeline-based custom rules require editing a TOML file * Handling custom rules at scale can feel complex for some teams ### Scope/Requirements 1. CRUD operations can be performed on via the UI or API. 1. CRUD operations are limited to Owner, Maintainer, and the custom role https://gitlab.com/gitlab-org/gitlab/-/issues/508649+ 1. Configurable settings include: 1. Default rules/detections 1. Disable 1. Secret Push Protection [Exclusions](https://gitlab.com/gitlab-org/gitlab/-/issues/480925) (directories/paths, values) -- patterns should likely no longer be included in exclusions as these are rules/default detections that could be disabled/enabled instead #### Engineering Assessment High-level Requirements ##### **Backend** * [ ] New configuration profile tables * [ ] Migration of existing `*project_exclusions` to profile tables * [ ] Ability to convert UI-based settings for scanner consumption * [ ] Work by ~"group::secret detection" to enable SPP scanner to consume exclusion patterns ##### **Frontend** * [ ] Ability to configure secret detection exclusions via scanner profile * [ ] Ability to apply profiles from the security inventory page #### Dependencies - Team dependencies: * Dependency on ~"group::secret detection" to handle backend implementation supporting ingestion of exclusions. - External dependencies: \[Any external dependencies\] #### DRIs - **PM**: @smeadzinger <!--also add as assignee to this epic--> - **EM**: @or-gal (Acting EM @rossfuhrman) <!--also add as assignee to this epic--> - **UX/PDM**: @mfangman <!--also add as assignee to this epic--> - **Group(s)**: ~"group::security platform management" <!--also add as label--> - **Engineering Owner**: @rvider #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated - Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades #### Sizing and Funding (Optional) - **Size**: \[L\] - **Funding Status**: \[Funded\]