## **Problem to solve** \ Enablement-only Dependency Scanning profiles provide zero-configuration deployment across projects. Security teams will need to validate whether default dependency vulnerability scanning meets their organizational needs, or if customization capabilities are required for their specific use cases. This epic explores **potential** custom configuration for Dependency Scanning. The **primary insight will come from customer validation** after enablement-only rollout. **How this improves from enablement-only**\ Enablement-only deployment solves the "turn it on everywhere" problem. Custom configuration would solve organization-specific dependency management requirements: * **From:** Zero-configuration scanner deployment with default vulnerability detection * **To:** Organization-specific configurations (if validation confirms need) ## **Experimental Scope** \ This epic contains **potential additional configuration capabilities** to explore after enablement-only deployment. Features are **subject to customer validation** - we will learn what customers actually need through their feedback on enablement-only adoption. **What customer validation will tell us:** * Do default dependency vulnerability scans provide sufficient coverage? * Do organizations need to customize which dependencies are scanned or how? * Are license policy configurations necessary? * Do teams need exclusion capabilities for known-safe dependencies or vendor code? * Do severity thresholds need customization for different dependency types? * Which customizations provide the most value for the effort? ## **Supporting context** \ Dependency Scanning was not included in [SPIKE analysis (#583778)](https://gitlab.com/gitlab-org/gitlab/-/issues/583778), so we have limited data on current customization patterns. **Customer validation will be the primary guide** for understanding Dependency Scanning customization needs. We're applying learnings from Secret Detection and SAST validation patterns, but dependency management may have unique requirements that differ from source code scanning. ## **Potential exploration areas** (if validation shows need): * Dependency exclusions (vendor code, known-safe packages, test dependencies) * License policy enforcement and allowlist/blocklist * Vulnerability severity thresholds and filtering * Package manager-specific configurations * Scanner version pinning for compliance requirements * Integration with dependency update workflows ## **Supported Package Managers** * JavaScript/Node.js: npm, yarn, pnpm * Python: pip, pipenv, poetry * Ruby: bundler * Java: maven, gradle * PHP: composer * Go: go modules * .NET: NuGet * See [Dependency Scanning documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) ## **Intended users** * Amy, Application Security Engineer - Primary * Alex, Security Operations Engineer - Secondary ## **Dependencies** * **Enablement-only Dependency Scanning profile** (must be in production first) * **Customer validation program** (primary dependency - critical for this scanner) * Secret Detection and SAST custom profiles (inform patterns and UX, if those proceed) * Security Inventory * AST team collaboration ## **Next Steps:** 1. Roll out enablement-only Dependency Scanning profiles 2. Gather customer feedback on default configuration limitations 3. Validate dependency-specific customization needs through actual usage 4. Define scope based on validation findings - this scanner has the least prior data **Critical Note:** \ Dependency Scanning is the most exploratory of all custom configuration epics due to lack of existing usage data. We should expect validation to reveal needs we haven't anticipated and be prepared to learn from customer feedback what (if any) customizations matter most for dependency management workflows.