## Problem to solve Enablement-only profiles (https://gitlab.com/groups/gitlab-org/-/work_items/19572 + https://gitlab.com/groups/gitlab-org/-/work_items/21110) give security and development teams zero-configuration scanner deployment, but they don't expose any way to tailor scanner behavior to an organization's needs. Customers who need custom secret patterns, path/file exclusions, external ruleset passthrough, or scanner version pinning have no supported UI path today — leaving them stuck with either raw YAML configuration or defaults that don't fit. This epic covers the product UI/UX design for **Advanced Configuration Profiles**: an extension of the enablement-only profile model that lets security teams define, manage, and apply custom scanner configuration at scale, while preserving the "one pattern, all profiles" consistency established by the enablement-only work. ## Proposal Extend the existing enablement-only profile model with **Advanced Configuration Profiles**: named, reusable scanner configurations that security teams can create, edit, and assign, sitting alongside GitLab-managed defaults in the same "Manage profiles" surface and the same enablement wizard. Rather than introducing a new mental model, this work reuses the patterns already validated for enablement-only profiles — General details, Scan triggers, Projects, Activity — and adds a scanner-specific "Advanced configuration" variable table so teams can override default analyzer behavior (exclusions, custom patterns, passthrough, etc.) through a guided UI instead of raw CI YAML. The result: one consistent profile experience, whether a team is applying a GitLab default or a custom profile they built themselves. ## Resources * [:joystick: Prototype](https://security-coverage-prototype-0b2bbb.gitlab.io/security-inventory-profiles/#/security-configuration) * :tools: [Repository for prototype](https://gitlab.com/gitlab-com/gitlab-ux/security-compliance-ux/srm-ux-group/security-coverage-prototype/-/tree/security-inventory-profiles) --- ## Scope * **Group-level profile management:** a new button on the Configuration page to surface management of profiles through a side drawer, covering profile list, creation, editing, duplication, and deletion for each scanner type (Dependency Scanning, SAST, Secret Detection, Container Scanning). * **List of profiles:** a list of available profiles for that scanner type, with a search bar at the top to filter though the list. Each item displays it's name, description, managed by and number of projects applied. * **Profile actions:** a primary action plus an overflow menu (Duplicate, Edit, Delete). GitLab-managed profiles cannot be edited or deleted: those actions are disabled with a tooltip, and Duplicate is the route to a custom copy. * **Duplicate opens a pre-filled form** named `X (copy)`, then `X (copy 2)`, and creates nothing until it's submitted. * **Submitting needs a name and at least one scan trigger on.** * **X and Esc in a form return to the profile** instead of closing the drawer. * **Permissions:** Developer can only view. Security Manager, Maintainer and Owner can do everything. Custom roles can split create and edit from delete. Unavailable actions stay focusable and explain themselves with the shipped "Action unavailable" copy. * **Copy matches what shipped:** toasts, empty text and form fields follow gitlab-org/gitlab!259383, !256222, !255995 and !257589. * **Profile configuration:** general details (name, description, analyzer type, managed by), Scan triggers (e.g. Merge Request Pipelines, Branch Pipelines, Push Protection), and Advanced configuration (the variable-key pairs per scanner type, e.g. `DS_EXCLUDED_PATHS`, `SECURE_ANALYZERS_PREFIX`). * **Per-trigger values:** a variable can hold a different value per scan trigger. When it does, the Value column reads `Differs by trigger` and expands to show each. A value set at the variable level applies to all enabled triggers. * **Additional variables:** a consistent "Add variable" flow for selecting from a scanner-specific set of supported analyzer variables rather than free-form YAML. * **Projects and Activity:** these tabs bring additional visibility to the usage of the profiles elected, the Projects tab (which projects use a given profile, their scan status, and last scan result) and Activity tab (audit history of profile changes). * **Project-level application:** the same drawer opens from a project's security configuration via "Switch profile", where the primary action is **Apply profile**. Group level configures profiles; project level applies them. * **Scanner Enablement Wizard:** in the "select scanners" step, the dropdown showing profiles to select shows a list of all profiles available for that scanner and a chip to signal ownership of the profile (e.g. `GitLab` / `Custom`). The "preview profile" modal is now extended to show additional configuration that a profile could have. **Out of scope for this epic**: Project context (credentials, scan targets, security attributes) and group-level bulk assignment via Security Inventory, which are covered by separate design efforts. ## Design choices 1. **One pattern for all profiles:** every scanner type uses the same interaction model for creating, editing, applying, and deleting profiles. The drawer interaction is consistent and only the configuration options (scan triggers, variables) are distinct. 2. **Progressive disclosure of complexity:** teams that only need enablement-only defaults are never forced into advanced configuration; teams that need customization can reach it without leaving the same surface. 3. **Self-service configuration:** security teams can see what's configured on a specific profile, history of changes for that profile and where it's applied, without engineering involvement or raw CI YAML.