Your security team requires all container images to be scanned before deployment, SAST on every merge request, and DAST on staging deployments. How do you integrate GitLab's built-in security scanning into your pipeline, handle findings, and enforce security gates?
Quick Answer
Include GitLab security scanning templates (SAST, Container Scanning, DAST, Dependency Scanning), configure security policies to require approval for critical vulnerabilities, use merge request approval rules tied to scan results, and implement compliance frameworks for enforcement.
Detailed Answer
GitLab Security Scanning Overview
GitLab provides built-in security scanners integrated directly into CI/CD: SAST (static code analysis), DAST (dynamic application testing), Container Scanning (CVE detection in images), Dependency Scanning (vulnerable libraries), Secret Detection (leaked credentials), and License Compliance. These produce standardized JSON reports that populate the Security Dashboard and merge request widgets.
SAST Integration
GitLab's SAST uses multiple analyzers based on language (Semgrep for multi-language, gosec for Go, bandit for Python). Include the template and it auto-detects languages. For monorepos, customize SAST_EXCLUDED_PATHS to avoid scanning generated code. Custom rulesets via .gitlab/sast-ruleset.toml can disable noisy rules or add organization-specific patterns. SAST runs on merge request diffs, showing only new findings introduced by the change.
Container Scanning and DAST
Container Scanning uses Trivy to analyze Docker images for OS and application vulnerabilities. Configure severity thresholds to fail the pipeline on critical/high CVEs. DAST runs against a deployed application (typically staging), performing automated penetration testing. DAST requires a running URL—use review apps or a dedicated staging environment. DAST profiles can be customized for authenticated scanning to test behind login pages.
Security Policies and Gates
Security policies (Ultimate tier) enforce scan execution and approval requirements without relying on project maintainers. A scan execution policy requires specific scans to run on every pipeline—teams cannot remove or modify them. A merge request approval policy requires security team approval when vulnerabilities of specified severity are detected. This creates a hard gate: code with critical vulnerabilities cannot merge without explicit security team sign-off.
Operationalizing Security Findings
The Vulnerability Report tracks all findings across projects. Vulnerabilities can be dismissed (with justification), confirmed, or resolved. Create issues directly from vulnerabilities for tracking. For large organizations, use the Security Dashboard at group level to see aggregate risk. Implement SLAs: critical vulnerabilities must be fixed within 48 hours, high within 1 week, medium within 1 sprint.