Advanced Configuration Profiles for Security Scanners (#20193) · Epics · GitLab.org

Advanced Configuration Profiles for Security Scanners

## Problem to solve Enablement-only profiles (Epic #19572) provide zero-configuration scanner deployment, but we need to validate whether customers require additional customization capabilities to meet their organizational security needs, or if defaults are sufficient for most use cases. **:chart_with_upwards_trend: North Star Metrics** (for overall Scanner Configuration Profiles initiative) 1. Increase adoption of active Ultimate projects to 70% usage ([Tableau](https://10az.online.tableau.com/#/site/gitlab/views/High-LevelSecurityMetricCharts/ofGitLab_comUltimateProjectswith2SecurityScannersRunning?:iid=1)) 2. Reduce Time-to-Value (remediation of first vulnerability) by 50% ([Tableau](https://10az.online.tableau.com/#/site/gitlab/views/SecureScannersTimetoValue/SecTimetoValue?:iid=1)) **Intended users** * Amy, Application Security Engineer * Alex, Security Operations Engineer * Isaac, Infrastructure Security Engineer ## Executive Summary This parent epic explores custom configuration capabilities that would extend enablement-only scan profiles with organization-specific customization. **The scope is subject to validation** - Q1 enablement-only adoption will inform whether, when, and which customizations to build. **Strategic Context:**\ Following leadership directive to deliver value through iteration: * **Q1 FY27:** Enablement-only profiles establish foundation (Epic #19572) * **Q2 FY27:** Potential MVC custom capabilities **IF validation confirms need** * **Q3 FY27:** Expansion OR pivot based on production usage data **Validation-Driven Approach:**\ We're not building custom profiles because we assume customers need them. We're building them IF Q1 validation proves they're necessary. This epic serves as the planning container for that potential work. ## The Strategic Question **Do customers need customization capabilities beyond enablement-only defaults?** Supporting context from [SPIKE #578208](https://gitlab.com/gitlab-org/gitlab/-/issues/578208): * 83% of SAST users configure Git passthrough (external rulesets) * 78% of Secret Detection users add custom patterns * 77% use exclusions to reduce false positives **But we need to validate:** * Are these needs still present with our enablement-only approach? * Do GitLab's scanner defaults reduce the need for customization? * Which customer segments actually need customization vs. those who are fine with defaults? * Is customization depth more valuable than scanner breadth? ## Current State: What Enablement-Only Provides Enablement-only profiles (Q1 delivery) solve: * Zero-configuration scanner deployment at scale * Bulk enablement through Security Inventory * Removal of YAML configuration burden * Project-level opt-out for developers What enablement-only **cannot** provide (if customers need it): * Organization-specific secret patterns or SAST rules * Path/file exclusions for false positive reduction * Scanner version pinning for compliance * Customizable scanner configurations **The question:** Are these gaps actually problematic, or are defaults sufficient? ## Potential Custom Configuration Capabilities **IF validation confirms need**, we would explore capabilities informed by [SPIKE analysis (#583778)](https://gitlab.com/gitlab-org/gitlab/-/issues/583778): ### Likely High-Priority (based on SPIKE data): 1. **Git passthrough for external rulesets** (83% SAST usage) - IF customers need org-managed rules 2. **Custom secret patterns** (78% Secret Detection usage) - IF defaults don't cover org-specific credentials 3. **Path/file exclusions** (77% usage) - IF false positives are problematic 4. **File/raw passthrough** (69% Secret Detection usage) - IF advanced users need direct analyzer control ### Exploratory (need more validation): 5. **Scanner version selection** - IF compliance requires pinning 6. **Environment variables** - IF specialized contexts emerge 7. **Additional scanner-specific options** - TBD based on customer feedback **Critical caveat:** These are **potential** capabilities based on what customers configure today. Q1 validation will determine: * Which (if any) are actually necessary * Priority order for implementation * Whether GitLab's defaults reduce or eliminate these needs --- ## User Journey (If We Proceed) **Hypothetical flow if validation confirms customization need:** 1. Security manager enables scanners via enablement-only profiles (Q1) 2. Observes scanner behavior, identifies friction (e.g., false positives, missing org-specific rules) 3. Requests customization capabilities through feedback 4. **IF sufficient demand validated**, we build targeted customization 5. Security manager extends default profile with custom configuration 6. Applies custom profile to relevant projects **Design principle:** Customization should be opt-in, not mandatory. Most customers should succeed with defaults. ## What Q1 Validation Will Tell Us [Epic #20196](https://gitlab.com/groups/gitlab-org/-/epics/20196) will answer: **Primary Questions:** * Do customers actually need customization, or are enablement-only defaults sufficient? * Which customizations provide the most value vs. effort? * Should Q2/Q3 focus on customization depth OR scanner breadth? **Secondary Questions:** * Which customer segments need customization? (regulated industries vs. tech/SaaS) * What friction points emerge from enablement-only that customization could solve? * Are there unexpected customization needs we didn't see in SPIKE data? **Possible Outcomes:** | Finding | Implication | |---------|-------------| | High demand for specific customizations | Proceed with targeted MVC in Q2 | | Defaults sufficient for most customers | Defer customization, focus on more scanner types | | Segment-specific needs | Tiered approach - advanced features for Ultimate | | Different customizations than SPIKE predicted | Pivot scope based on actual customer requests | ## Success Criteria (If We Proceed) **We'll only build custom profiles if validation shows:** * Clear customer demand for customization capabilities * Specific use cases that enablement-only doesn't address * Willingness to adopt custom profiles (not just theoretical need) **IF we proceed, success looks like:** * Customers can configure scanners to match organizational needs * Customization doesn't become a barrier to adoption * Support burden decreases (customers self-serve configuration) * Competitive positioning improves vs. Snyk/Wiz/GitHub Advanced Security **Metrics we'll track:** * % of customers using custom profiles vs. remaining on defaults * Which customization features see actual adoption * Customer satisfaction with configuration capabilities * Impact on scanner opt-out rates ## Dependencies **Prerequisites:** * Epic #19572: Enablement-only profiles in production * Epic #20196: Q1 validation SPIKE complete with clear recommendation * Security Inventory stable and GA * Customer Zero validation program active **Collaborators:** * Grant Hickman (Security Policies PM) - cross-group alignment * Mike Clausen (Security Insights PM) - Security Dashboard implications * Or Gal (Engineering Manager) - feasibility and implementation * Dean Agron (Group PM) - strategic direction * AST team - scanner-specific validation and collaboration ## What's Next **Immediate:** 1. Complete Q1 enablement-only profile rollout (Epic #19572) 2. Begin validation SPIKE (Epic #20196) 2-3 weeks after launch 3. Gather customer feedback on enablement-only experience **Q2 Decision Point:** * Review validation findings with Dean, Or, Grant, Mike * Decide: Proceed with custom MVC, pivot to scanner breadth, or iterate on enablement-only * If proceeding: Define specific Q2 scope based on validated customer needs **Q3 Decision Point:** * Review Q2 custom profile adoption (if built) * Decide: Expand customization depth OR pivot to more scanner types * Adjust roadmap based on production learnings ## Notes * **This is exploratory work**, not committed delivery * Child epics (Secret Detection, SAST, Container Scanning, Dependency custom profiles) are **experimental** and subject to validation outcomes * SPIKE data provides context and hypotheses, **not commitments** * We're prepared to pivot if validation shows different customer needs * "Done" means validated direction and customer value, not feature completion ## What is the type of buyer? - CISO - Application Security Engineer supporting decisions by CISO ## Is this a cross-stage feature? Yes, in that we must be aligned across: - **Group:** Security Platform Management (DRI: @m-omokoh) - **DevOps:** Application Security Testing (AST scanners) - **Related Groups:** Security Policies, Security Insights ## Links / references - **Parent Epic:** [AST Scanner Configuration Profiles (#16204)](https://gitlab.com/groups/gitlab-org/-/epics/16204) - **Enablement-Only Profiles (Q1):** Epic #19572 - **SPIKE Analysis:** [Issue #578208 - Analyze usage of current analyzer configuration methods](https://gitlab.com/gitlab-org/gitlab/-/issues/578208) - **Security Platform Management Direction:** [Direction Page](https://about.gitlab.com/direction/security_risk_management/) - **Q2 Strategic Direction Document:** \[Issue TBD - to be created\] --- ## Important This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.   > [!important] > This page may contain information related to upcoming products, features and functionality. > It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. > Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

epic