## Problem to solve Security teams need a fast, low-friction way to activate dependency scanning across their projects without configuring it from scratch. This issue covers the design of the Dependency Scanning 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 SAST. Like SAST, Dependency Scanning uses two pipeline-based triggers — one for fast feedback during development and one for comprehensive coverage of the default branch. ## Scope This issue covers the UI/UX for the Dependency Scanning enablement-only profile, including: 1. **Profile description:** Concise explanation of what the profile protects against, what triggers are included, and when scans run — using the established description pattern from other profiles 2. **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 3. **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 4. **Consistency with other enablement-only profiles:** The Dependency Scanning profile should follow the same structural and interaction patterns as the Secret Detection and SAST 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 1. Validated design specifications for the Dependency Scanning enablement-only profile 2. Designs showing the profile in context, consistent with the Secret Detection and SAST profiles 3. Documentation of any Dependency Scanning-specific design decisions that emerge during the design process 4. Handoff-ready documentation for engineering ## Deliverables 1. [Figma design file](https://www.figma.com/design/4oNSvHiCso7EXypEtLSSc6/Dependency-configuration?node-id=2-46708&t=p5A1RXHa36Bb9TU0-4)