<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=591552) </details> <!--IssueSummary end--> ## Problem to solve Security teams need a fast, low-friction way to activate static application security testing across their projects without configuring it from scratch. This issue covers the design of the SAST enablement-only configuration profile — a GitLab-managed, read-only profile that users can apply to projects but cannot modify. Scan triggers, detection rules, and all other settings are predefined by GitLab. This is part of the broader configuration profiles MVC, which also includes enablement-only profiles for Secret Detection and Dependency Scanning. Unlike Secret Detection, SAST does not include a push-time blocking trigger — both of its triggers are pipeline-based, and understanding the distinction between them (fast feedback during development vs. comprehensive scanning of the default branch) is important context for users evaluating the profile. ## Scope This issue covers the UI/UX for the SAST enablement-only profile, including: - **Profile description:** Concise explanation of what the profile protects against, what triggers are included, and when scans run - **Scan trigger presentation:** Read-only display of the profile's two configured triggers — merge request pipelines (scans changed files for fast feedback during development) and branch pipelines (scans the full repository when changes are merged to the default branch) — consistent with how other enablement-only profiles present trigger information - **Read-only treatment:** How pre-configured settings are surfaced to communicate that this is a managed profile — users should understand what's configured without being confused by why they can't edit it - **Consistency with other enablement-only profiles:** The SAST profile should follow the same structural and interaction patterns as the Secret Detection and Dependency Scanning profiles, with only scanner-specific content differing ## Design goals 1. **Transparency over configuration:** Since the profile is read-only, the design should help users understand exactly what they're enabling — which triggers fire, when, and what each is optimized for (incremental feedback on MRs vs. comprehensive coverage of the default branch) 2. **Frictionless activation:** Applying the profile to a project should require minimal steps and feel like an obvious, low-risk action 3. **Scalability:** The design should use the same structure as other enablement-only profiles so the pattern extends cleanly across scanner types ## Expected outcomes - Validated design specifications for the SAST enablement-only profile - Designs showing the profile in context, consistent with the Secret Detection and Dependency Scanning profiles - Documentation of any SAST-specific design decisions, particularly around how the two pipeline triggers are distinguished and communicated to users - Handoff-ready documentation for engineering ## Deliverables 1. [Figma design file](https://www.figma.com/design/XqGRppl7NU8ngc2huAes4M/SAST-configuration?node-id=54-60019&t=5Lk3nMETitnRfn6G-4)