## Release notes **Customize security configuration profiles for Secret Detection, SAST, and Dependency Scanning** You can now customize Secret Detection and SAST profiles in the UI. Set scan options such as exclusions, custom analyzer images, and historic scanning once, at group level, and apply them across your projects. Previously, a security configuration profile enabled a scanner with its default settings. Anything beyond the defaults meant going back to per-project `.gitlab-ci.yml`. Now the profile carries the configuration too. Dependency Scanning profiles gain the same customization through the GraphQL API in this release, with the UI following in 19.6. https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/ > **Note:** The source of truth for this release note has moved to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260800. Edit the MR directly to make changes. --- ## Problem to solve Enablement-only Secret Detection profiles solved zero-configuration deployment: turn SD and SPP on across many projects with GitLab defaults. That serves customers with standard needs. But customers who need to tailor how detection runs, custom secret patterns, exclusions, passthrough configuration, cannot rely on defaults alone, and validation shows they are a large share of the base. This epic covers the customization layer for unified Secret Detection (push protection + pipeline). It is no longer exploratory: customer validation and configuration data have confirmed the need. The customization API shipped last milestone; the focus now is bringing that configuration to the profile UI. ## From enablement-only to advanced configuration Enablement-only solved "turn it on everywhere." Advanced configuration solves "make it work for our organization": * **From:** zero-configuration deployment with GitLab defaults * **To:** customer-managed configuration, custom secret patterns, exclusions, and passthrough, defined once and applied at project and group scope ## Validation (the need is confirmed) Grounded in configuration data and customer signal, not assumption. **Configuration data** ([SPIKE #583778](https://gitlab.com/gitlab-org/gitlab/-/issues/583778), 408 customer Secret Detection configurations): * 78% customize secret patterns * 77% use exclusions * 69% use file or raw passthrough configuration These are not edge cases, the majority of customers customize SD today. Defaults alone don't meet the need for most. **Customer signal:** * Qube (Ultimate upgrade eval): needs control over Secret Push Protection exclusions specifically, wants push protection without duplicated pipeline scanning. Exclusion authoring is a live blocker. * Broader field feedback: consistent demand to customize detection centrally rather than per-project, and to control who can set exclusions (the SPP exclusions thread, where exclusion enhancements were held pending availability via Configuration Profiles). ## Delivery state and scope **Shipped (last milestone):** the customization API for unified Secret Detection. **In progress (19.4, scope being finalized with engineering):** bringing the customization to the profile UI, so customers can configure SD/SPP in the interface rather than only via API. The guiding principle: expose the variables the API already supports today, presented with human-readable labels (the UI shows a friendly name plus the underlying variable, e.g. "Analyzer image registry" for `secure_analyzers_prefix`). We're wiring UI to operations the backend already does, not building new backend. Scope for the 19.4 slice to be confirmed with engineering given capacity and milestone timing; if the full set doesn't fit, we ship a meaningful first slice and continue in 19.5. The customization surface the API supports today (grouped by capability, per the AST team's carry-forward variables): * **Exclusions** (the SPP-exclusions answer): path, raw-value, and rule exclusions, newly introduced specifically to manage exclusions for both SPP and pipeline. This is the capability the field has been waiting on, exclusion authoring in Configuration Profiles, gated by profile access. (77% of customers use exclusions per the SPIKE.) * **Custom scanner images**: analyzer image registry (`secure_analyzers_prefix`, shared with SAST) and image suffix, to pull from a customer's own registry. * **Scan behavior**: historic scanning, log options. **Not in the API-ready set (out of scope for now)** We don't need to enumerate every variable here, the scope is "what the API exposes today, surfaced with good labels." The exclusion, image, and scan-behavior variables above are the API-ready set for the UI. ## Intended users * Amy, Application Security Engineer, primary * Alex, Security Operations Engineer, secondary ## Dependencies * Enablement-only Secret Detection profile (18.9 GA) * Secret Detection customization API (shipped) * Frontend design for the profile UI (in progress, dependency for the 19.4 slice) * Security Inventory * AST team collaboration ## Next steps 1. Confirm the 19.4 UI scope with engineering (smallest realistic slice given capacity + timing). 2. Finalize the frontend design/implementation plan. 3. Expose the shipped customization API in the profile UI, prioritizing the highest-signal surfaces (patterns, exclusions). 4. Align with the SPP exclusions work, the profile UI is the intended home for exclusion authoring gated by profile access.