**TEAM DECISION:** One Auto-Resolve profile per scan type, combining remediation and Contextual Intelligence into a single profile, built and rolled out in three phases: Crawl, Walk, Run. #### Maturity Framework This epic ships in three deliberate phases, not because the full scope isn't understood, but because each phase depends on the previous one being validated in production: * **Crawl:** The API supports full configuration from day one, severity thresholds, CWE targeting, fix-type/MR caps, everything Walk will eventually expose. Customers integrating directly against the API can customize immediately. The Crawl **UI**, however, is enablement-only: a one-click Standard or Aggressive preset, no per-flow tuning surfaced. Walk's job isn't to add new API capability, it's to build the UI that exposes what the Crawl API already supports, scanner by scanner. Covered by Auto-Resolve Configuration Profiles (API) and Auto-Resolve Configuration Profiles (UI), Enablement-only. * **Walk, customization:** UI for the per-scanner, per-feature configuration the Crawl API already supports, severity thresholds, CWE targeting, fix-type and MR caps, flag-only vs. flag-and-dismiss for FP handling. Covered by three epics: Customization: SAST, Customization: Dependency Scanning, Customization: Secret Detection. * **Run, Automations:** A condition-to-action layer (Fangman's term) that lets a flow's behavior depend on another flow's output, e.g. only run Vulnerability Resolution if Vulnerability Context already flagged a finding as high-risk. This is what was previously called "orchestration." Covered by Auto-Resolve Configuration Profiles, Orchestration. Each phase is designed with the next in mind, but ships independently. Walk does not block on Run being fully scoped; Run's data model assumes Walk's per-feature configuration exists. #### Problem Statement GitLab is building a powerful set of AI and programmatic capabilities across vulnerability management: auto-remediation for SAST, Secret Detection, and Dependency Scanning, and contextual intelligence (SAST FP, Vulnerability Context/SDLC agents) that helps security teams triage findings faster and with more confidence. These capabilities fall into two distinct jobs to be done: * **Auto-remediation (Fix it for me):** the system identifies a vulnerability and opens a fix automatically. * **Contextual Intelligence (Help me decide):** the system adds context to a finding so a security team can prioritize and act with confidence. As these capabilities ship, each one risks getting its own bespoke configuration surface: SAST VR has one path, DS programmatic auto-remediation has another, FP Detection has another. There is no group-level management, no bulk enablement, and no consistent model across scan types. This creates operational friction for enterprise customers managing hundreds or thousands of projects, slows adoption, and forces security teams to learn multiple configuration systems as GitLab's AI capabilities mature. It also means that as flows mature from "run independently" to "run conditionally on each other's output", there's nowhere for that logic to live. The goal is a single Auto-Resolve profile per scan type, covering both capability buckets, built in three phases so customers get value at each step instead of waiting for the full system. #### Why This Matters Security teams managing large namespaces need one place to configure vulnerability management workflows across their organization. Today that does not exist. Each feature has its own configuration path, often at the project level, with no group-level management or bulk enablement. For customers like Swisscom (39,000 projects) or IQVIA (55,000 projects), project-by-project configuration is not a workflow, it is a blocker. A unified surface also ensures programmatic and AI-driven remediation share the same configuration model, so customers don't relearn the system as AI capabilities mature and replace programmatic ones. And it gives usage-based billing customers a way to control cost: Becka's feedback confirms customers want flows to run conditionally, only spending credits on the highest-risk findings, which the Run phase directly addresses. #### Scope **Remediation (fix it for me):** * SAST Vulnerability Resolution (AI-driven, by CWE): #21944 * Secret Detection auto-remediation: not on the roadmap * DS programmatic auto-remediation: #21462, plus AI **Contextual Intelligence (help me decide):** * SAST FP Detection (severity-based): `#582100` * Secret Detection FP analysis * Vulnerability Context/Enrichment agent: #20894 **Configuration surface capabilities:** * Auto-remediation and Contextual Intelligence live in a single combined Auto-Resolve profile per scan type (SAST, DS, Secret Detection), not two separate profiles. This mirrors the pattern used for scan profiles, but with triage and remediation merged into one profile per Fangman's latest design. * Auto-remediation surfaced on its own tab on the project-level security configuration page. * Applying profiles at the project level and at the group level. * Group-level profile assignment: a default profile plus assignment rules based on security attributes. Placement (dedicated UI vs. Security Policy) is an open question, see Open Questions below. * Bulk enablement via SPM workflows (Security Inventory, CES), not project by project. * Profile-based management is the exclusive configuration mechanism. Individual project configuration outside of profiles is the legacy path and is not in scope. * Within a profile, triggers and severity targeting are configurable per feature (Walk phase), not dictated by one global setting for the whole profile. * FP handling distinguishes flag-only from flag-and-dismiss, rather than a single automated action. **Automations (Run phase):** * A condition-to-action layer at both group and project level: if a flow's output meets a condition, trigger another flow or action (e.g. only run Vulnerability Resolution if Vulnerability Context already flagged a finding, or dismiss a finding if FP Detection returns high certainty). * Actions today: execute VR, change severity, dismiss vulnerability. Future: set due date. * Depends on the Vulnerability Context Metadata cardinality epic (#21760) for the condition values, and on trigger documentation (#22407) for how flows fire. * Open question, not yet resolved: does Automations live standalone, inside the Auto-Resolve profile, or inside Security Policy. **Profile structure:** * Each scan type (SAST, DS, Secret Detection) gets its own combined Auto-Resolve profile, applied independently. * Future consideration: a single unified profile combining scan configuration, remediation, and Contextual Intelligence across all scan types into one decision. Not in scope for initial delivery, but the long-term direction, and Crawl/Walk should be designed with this compatibility in mind. **Initial delivery (Crawl):** * The Crawl API ships with full configuration support, not just on/off, so it's ready for direct API consumers and for Walk to build UI against without further API work. The Crawl UI ships enablement-only: apply a GitLab-recommended default profile (Standard) or a maximum-coverage profile (Aggressive), one click, no per-flow tuning exposed. Walk is UI work on an already-capable API, not new backend scope. **Customization options per feature (Walk):** * **FP Analysis (AI-driven):** severity threshold controlling which severity levels trigger FP analysis; flag-only vs. flag-and-dismiss. * **SAST VR (AI-driven):** CWE targeting, enable or disable VR by specific CWE. * **DS Programmatic Auto-remediation:** severity level targeting (Low/Medium/High/Critical); version update strategy (Major/Minor/Patch); max open MRs, range 1 to 10, beta default 5. #### Out of Scope * The underlying auto-remediation and contextual intelligence detection engines themselves. Owned by CA (DS programmatic), the Security Insights Group (SAST VR, FP Detection), and the Secret Detection team respectively. * Individual project configuration outside of profiles. Legacy path, not being invested in. * Custom (fully bespoke) profile creation beyond Standard and Aggressive, deferred past initial delivery. * Defining new vulnerability-context values, owned entirely by #21760. #### Open Questions * **Automations placement:** standalone surface, inside the Auto-Resolve profile, or inside Security Policy. Raised by Fangman, has direct bearing on Run-phase scope and ownership. * **Group-level assignment placement:** dedicated UI or Security Policy, the same underlying question as above, raised for both tabs in Fangman's walkthrough. * **Default profile behavior clarity:** does "Turn on Auto-Resolve" apply Standard by default, or Aggressive if enabled at the group level, and how is that made clear to the user (Becka's medium-priority note). * **Profile preview:** should customers be able to preview what a profile does before applying it (Becka's medium-priority note). * **Flow dependency chaining:** confirmed customer need (Becka, high priority) for flows to run conditionally on another flow's output. This is now explicit scope for the Run phase, not a nice-to-have. #### Dependencies * CA API for DS programmatic auto-remediation, targeting 19.2. * Security Insights Group's flows migration work: alignment on moving flow configuration to an SPM-owned surface. * Fangman's prototype and design: customer validation needed before engineering begins on Walk and Run. Celeste North is picking up reframing the security configuration wizard, which currently assumes scanning only. * Vulnerability Context Metadata cardinality epic (#21760): defines the condition values Automations depends on. * Trigger documentation (#22407): defines how flows fire (pipeline execution, MR creation, cron). * Marissa's Security Experience Decision Framework: configuration surface must align with the agreed framework. * Auth team: permissions for the Security Manager role to configure these surfaces. * A decision on where Automations and group-level assignment live (dedicated UI vs. Security Policy), needed before Run-phase scoping starts. #### Design Principles * **Build once, not twice.** The configuration surface supports both programmatic and AI-driven remediation from the start. No bespoke surfaces that need rebuilding as AI capabilities mature. * **Consistent with profiles.** Auto-Resolve Profiles follow the same pattern as Configuration Profiles for scanner enablement. * **SPM workflows as the entry point.** Bulk enablement and management happen through Security Inventory and CES, not project by project. * **Aligned with AI tab direction.** Agentic activity is surfaced through the AI tab with pointers from the SPM configuration surface, per Marissa's framework. * **Crawl, Walk, Run.** Ship enablement first, add per-feature customization next, add conditional automation last. Each phase ships independently and is validated before the next is scoped in detail. #### Customer Validation Before Walk and Run engineering begins, validate Fangman's prototype with design partners. Key questions: * Does the Auto-Resolve profile pattern resonate with security teams? * Should DS, SAST, and Secret Detection profiles be applied independently or together? * What per-feature configuration do customers actually need beyond on/off? * Is group-level bulk enablement sufficient, or do customers need subgroup-level control? * Does the unified profile concept (scan + remediation + Contextual Intelligence in one) resonate for the long term? * Does flag-only vs. flag-and-dismiss cover the FP handling customers actually want? * Do customers need flow-dependency chaining (Becka's finding) as part of initial Walk delivery, or is that acceptable to defer to Run? Design partners to engage: TBD. #### Target Milestone * **Crawl (API):** 19.4 * **Crawl (UI, enablement-only):** 19.5 * **Walk (Customization: SAST, Dependency Scanning, Secret Detection):** 19.6 through 19.8 * **Run (Automations):** not yet scheduled, pending resolution of the Automations placement question and customer validation #### Proposed DRIs * PM: @m-omokoh * Design: @mfangman @c_north * Engineering: @gkatz1