## Problem to solve Enablement-only SAST profiles solved zero-configuration deployment: turn SAST on across many projects with GitLab-provided defaults. That serves customers with standard needs well. But customers who need to tailor how SAST runs, custom rulesets, exclusions, and their own scanner images, cannot adopt profiles today, and they are a large share of our enterprise base. This epic covers the customization layer for SAST profiles. It is no longer exploratory: customer validation post-enablement has confirmed the need. The work now is to define and ship the customization capabilities that let customization-needing and existing SEP/YAML customers adopt SAST profiles. ## From enablement-only to advanced configuration Enablement-only solved "turn it on everywhere." Advanced configuration solves organization- and team-specific requirements: * **From:** zero-configuration deployment with GitLab-provided rules * **To:** customer-managed configuration, custom rulesets (including external/Git-referenced), exclusions, and custom scanner images, applied at project and group scope (and organization scope when available) ## Validation (the need is confirmed) This is grounded in named-customer evidence and configuration data, not assumption. **Customer signal** (tracked in [#606309](https://gitlab.com/gitlab-org/gitlab/-/work_items/606309)): **Configuration data** ([SPIKE #583778](https://gitlab.com/gitlab-org/gitlab/-/issues/583778), 387 Semgrep/SAST customer configurations): * 83% use Git passthrough to reference external rulesets * 91% use some form of passthrough configuration * Confirms an external-ruleset workflow pattern (distinct from Secret Detection's inline pattern) Together these establish that customization, especially external ruleset references and exclusions, is a real adoption blocker for the enterprise segment, not a hypothesis. ## Scope Scope is defined by the SAST variables the AST team has flagged to carry forward to Scan profiles (per the shared AST Variables source). Grouped by capability: * **Custom scanner images** (Customer blocker): `SECURE_ANALYZERS_PREFIX` (mirrored/custom registry), `SAST_ANALYZER_IMAGE_TAG` (pin analyzer image version). * **Exclusions** (noise reduction): `SAST_EXCLUDED_ANALYZERS`, `SAST_EXCLUDED_PATHS`. * **Advanced SAST scan behavior**: `ADVANCED_SAST_PARTIAL_SCAN`, `GITLAB_ADV_SAST_INCR_SCAN` (both not currently in SEP). **Open scope question, external Git rulesets.** The SPIKE data shows 83% of customers use Git passthrough to reference external rulesets, making it the single highest-signal customization. However, `SAST_RULESET_GIT_REFERENCE` is currently marked as _not_ carrying forward to Scan profiles in the shared AST source. This tension needs resolving with the AST team: if external ruleset references are the top customer need, we should confirm whether this variable can be brought into profile scope, or understand why it is handled separately. Flagging as the key scope decision before build. Per-capability sequencing to be refined during 19.4 planning with engineering, prioritized by customer signal (custom images and exclusions have direct named-customer blockers; external rulesets have the strongest aggregate data signal but an open carry-forward question). ## Supported languages Advanced SAST customization follows Advanced SAST's supported languages, GA and Beta. If Advanced SAST supports a language, it is customizable via profiles. Current coverage: JavaScript/TypeScript, Python, Java, Ruby, Go, C#/.NET, PHP (GA), and Objective-C/Swift (Beta), expanding as Advanced SAST adds languages. **Decision:** customization tracks Advanced SAST's full language support rather than GA-only. This means no separate gating logic to exclude Beta languages (simpler to build), Beta-language users (e.g. Objective-C/Swift today) can customize immediately rather than waiting for GA, and new languages are covered automatically as Advanced SAST adds them. This resolves Ross's question, no code needed to exclude non-GA Advanced SAST languages. See [GitLab Advanced SAST documentation](https://docs.gitlab.com/user/application_security/sast/#gitlab-advanced-sast). ## Intended users * Amy, Application Security Engineer, primary * Alex, Security Operations Engineer, secondary ## Dependencies * Enablement-only SAST profile (shipped) * Security Inventory * AST team collaboration * [#606309](https://gitlab.com/gitlab-org/gitlab/-/work_items/606309) customer feedback tracking ## Next steps 1. Confirm variables need from the SAST team IN PROGRESS 2. Define per-capability scope and sequencing for 19.4, starting with external ruleset references (highest-signal from SPIKE + customer evidence). DONE 3. Align profile-vs-policy boundary for any enforcement aspects (per the agreed model: profile owns config, applied via wizard, referenced by policies). IN PROGRESS 4. Build against validated need, sequenced by customer signal.