Beta Release: Automatic Detection of Secret Scanning False Positives (Vulnerability Report + Security Configuration Page)
## Executive Summary
This epic covers the implementation of AI-powered automatic detection of false positives in Secret Scanning results. This feature will leverage AI to proactively identify and flag potential false positives in Secret Detection findings before developers attempt to resolve them, significantly reducing alert fatigue and improving the signal-to-noise ratio of security scanning.
The solution will analyze Secret Detection findings to identify test credentials, example values, and dummy secrets that are incorrectly flagged as actual security vulnerabilities, providing clear explanations and confidence scores for each determination.
#### Engineering Assessment
This feature builds upon existing false positive detection capabilities in GitLab's Secret Detection scanner and extends them with AI-powered analysis. The implementation will integrate with multiple surfaces in the GitLab UI (MR widget, pipeline security tab, and vulnerability report) to provide comprehensive coverage.
Key technical components:
- AI-powered false positive detection with confidence scoring
- Clear explanations for FP determinations
- Integration with existing Secret Detection workflow
- Bulk dismiss/accept capabilities
- Metrics tracking for precision, recall, and confidence correlation
#### Dependencies
- Team dependencies:
- Sec AI Experiments team (primary development)
- Static Analysis group (Secret Detection scanner integration)
- Duo Workflow team (AI infrastructure)
- Epic/Issue dependencies - Link to dependent epics/issues via the linked items widget below for ease of drill down
- External dependencies: None
#### DRIs
- **PM**: @khornergit
- **EM**: @nrosandich
- **UX/PDM**: @acummins9
- **Group(s)**: ~"group::compliance"
- **Engineering Owner**: @nrosandich
#### Initiative Driver - Product or Engineering?
- [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment
- These initiatives require a Product Priority label (P1/P2/P3)
- They may also receive GTM tier labels (T1/T2/T3) for external communication
- [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components
- These initiatives require an Engineering Priority label (E1/E2/E3)
- They have internal visibility only and are not externally communicated
- Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades
#### Sizing and Funding (Optional)
- **Size**: L
- **Funding Status**: Funded
---
### Hygiene Guidelines
:bulb: See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/
##### :one: Pre-Interlock
- [x] Update epic description with all relevant information
- [x] Ensure all dependencies are identified
- [x] Apply appropriate labels (see below)
- [x] Apply target delivery Milestone
- [ ] Update interlock status as discussions progress (via label)
##### :two: Post-Interlock: once quarter begins
- Update health status weekly (via label)
- Document any newly identified risks or dependencies
- Link to implementation epics/issues as work begins
- Flag any scope or timeline changes immediately
---
## Related Work
- Parent Epic: https://gitlab.com/groups/gitlab-org/-/work_items/17885 (Automatic Detection of Secret Scanning False Positives)
- Experiment Phase: https://gitlab.com/groups/gitlab-org/-/work_items/18332
epic