### Overview This epic tracks the work necessary to provide maintainers and owners of projects/groups the ability to exclude certain paths, regex patterns, or raw values from being scanned, detected, and blocked by [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection) using a [UI-managed exclusions list](https://gitlab.com/groups/gitlab-org/-/epics/13993). #### Scope To break the scope of this epic down, we have decided to go with a phased approach, in which we tackle certain tasks first in order to improve the delivery pace so ~frontend doesn't have to wait so long for ~backend to finish up all necessary work before kicking off work. It would also allow us to deliver project-level exclusions to our users and gather their feedback while working on group-level exclusions. At the end of each phase... 1. [**Phase 1**: a user will be able to manage a list of excluded paths/patterns/values for projects](https://gitlab.com/groups/gitlab-org/-/work_items/14878). 1. [**Phase 2**: a user will be able to manage a list of excluded paths/patterns/values for groups as well as projects](https://gitlab.com/groups/gitlab-org/-/work_items/14879). #### Proposal The following is a high-level overview of tasks required to achieve the outcome outlined in the scope: On the ~backend side... * **Phase 1.1**: * Introduce database tables to support exclusions on both project and group levels. * Define and set roles that can manage exclusions on project-level. * Introduce the API interface for managing exclusions on the project-level. * Introduce REST API resources for managing exclusions on the project-level. * Introduce GraphQL resources for managing exclusions on the project-level. * Update secret push protection to excluse findings based on existing exclusions. * Update scanning engines (e.g. gem and secret detection service) to handle exclusions. * **Phase 2.1**: * Define and set roles that can manage exclusions on group-level. * Introduce the API Interface for managing exclusions on the group-level. * Introduce REST API resources for managing exclusions on the group-level. * Introduce GraphQL resources for managing exclusions on the group-level. * **Phase 3.1** (_**provisional**_ since it still requires some research): * Add support for another scanner (e.g. Pipeline SD). On the ~frontend side... * **Phase 1.2**: * Add the interface to manage exclusions on project-level. * Update project security configuration page to link to a new exclusion settings page. * Add an empty state for the exclusion settings page. * Add the exclusion settings page to be used manage exclusions. * Add a new item/edit item component. * Add a display item component. * **Phase 2.2**: * Add the interface to manage exclusions on group-level. * Update group security configuration page to link to a new exclusion settings page. * Add an empty state for the exclusion settings page. * Add the exclusion settings page to be used manage exclusions. * Add a new item/edit item component. * Add a display item component. #### Decisions These are a list of decisions we have made based on our [recent technical discovery sync discussion](https://docs.google.com/document/d/1Rq94C0B9mo4EMQNWCovq4O0p5C1BKaa7L9ClqaiSaEM): * **Storage**: Exclusions data will be stored in the database (read more on the why [here](https://docs.google.com/document/d/1Rq94C0B9mo4EMQNWCovq4O0p5C1BKaa7L9ClqaiSaEM/edit#bookmark=id.ry7auzttdik2)). * **Scanners Support**: Scoped to _Secret Push Protection_, but will be expanded to other scanners in later iterations. * **Levels**: The feature will initially be available on both the _project_ and _group_ levels. * **Entry Types**: Exclusions will support the following types of entries: * **Paths**: specific file paths or simple `glob` patterns can be excluded from scanning. * **Rules**: certain rules can be excluded from scanning. * **Raw Values**: certain raw values can be excluded from scanning. * **Permissions**: Only maintainers+ are allowed to manage exclusions.