## Overview This epic leads to the next iterative milestone for [Secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection). Our goals for this iteration are: * Releasing the feature for GitLab Self-Managed. * Meeting [GA maturity criteria](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#generally-available-ga). We decided to work on both goals together because we have already made this available for customers on GitLab SaaS (.com and Dedicated), and we wanted to extend this feature to all customers when it becomes generally available. ## Scope ### Summary After the work in this epic is complete: 1. We will limit scanning of secrets to a set of changes (the delta). This is especially important to avoid having an awkward and confusing user experience as users could run into situations where they push a file that contained a secret in a prior push (that was skipped), and still get notified about the secret. 2. We will introduce an allowlist feature in order to support various workflows: - As a developer: reduce irrelevant secret detection findings, so that I can maintain an efficient workflow. - As an AppSec practitioner: eliminate specific secret detection findings, so that I reduce as much organizational friction as possible, and reduce time spent triaging unnecessary findings, while using secret detection to maintain good security controls. 3. We will offload the scanning logic to a standalone RPC service to increase the reliability by reducing the load on our core platform (Rails platform and Gitaly). This also increases scalability by allowing us to autoscale the service depending on the potential increase of scanning requests. 4. We will centralize the patterns we use across the different types of scanning. By centralizing to a SSoT we will be able to ensure the results are consistent across the platform based on the pattern definitions. This will additionally allow us to decouple the patterns from the engine, opening up an opportunity to version rules. This will improve maintainability of our SD rulesets, as well as enable us to efficiently release pattern improvements and additions. 5. We will allow enabling/disabling on the feature at the group-level in addition to project-level. This will be especially important for security teams so they have better control of the feature and are able to track which groups and projects have the feature enabled or disabled. ### Details (**[Epic Dashboard](https://epic-dashboard-gitlab-org-tenant-scale-group-4aecf10d1d02154641.gitlab.io/epic_13107)**) Reaching this goal will require: 1. Improvements to customer workflows... * Epic: &14314+ * Epic: &14315+ 2. Ensure platform reliability... * Epic: &13792+ * Epic: &14200+ 3. Increase ease of adoption * Epic: &14307+ * gitlab-org/gitlab#441655+ * gitlab-org/gitlab#469405+ 4. Gather product insights * Epic: &12917+