How do you configure security scanning (SAST, DAST, dependency scanning) in GitLab CI/CD pipelines?
Quick Answer
GitLab provides built-in security scanning templates for SAST (static code analysis), DAST (dynamic application testing), dependency scanning, container scanning, and secret detection. You enable them by including GitLab's official CI templates, and scan results appear as widgets in merge requests with vulnerability severity ratings.
Detailed Answer
Think of GitLab security scanning like the inspection stations in a car manufacturing plant. SAST is the blueprint reviewer who examines the engineering drawings (source code) for design flaws before the car is built. Dependency scanning is the parts inspector who checks that none of the imported components (third-party libraries) have known recalls (CVEs). Container scanning is the assembly-line inspector who examines the finished vehicle (Docker image) for structural weaknesses. DAST is the test driver who takes the car onto the track (running application) and tries to crash it. Secret detection is the quality controller who checks that no factory keys were accidentally left in the glove compartment (hardcoded credentials).
GitLab's security scanning suite is available in the Ultimate tier (some features in Premium) and is integrated directly into the CI/CD pipeline. You enable scans by including GitLab-managed CI templates in your .gitlab-ci.yml using the include keyword. Each template adds jobs to your pipeline that run the appropriate scanning tools: SAST uses analyzers like Semgrep, ESLint, Gosec, and SpotBugs depending on the detected languages; dependency scanning uses Gemnasium, Bundler Audit, or Retire.js; container scanning uses Trivy or Grype to examine Docker images; DAST uses a proxy-based scanner against a running application URL; and secret detection uses Gitleaks to find hardcoded passwords, API keys, and tokens. Each scanner produces a standardized JSON report that GitLab parses and displays in the merge request.
Internally, when you include a security scanning template, GitLab adds one or more jobs to your pipeline. These jobs pull analyzer Docker images maintained by GitLab, mount your source code or built artifacts into the container, and execute the scan. The analyzer outputs a standardized JSON report file (gl-sast-report.json, gl-dependency-scanning-report.json, etc.) which the job uploads as a report artifact. GitLab's backend parses these reports and cross-references findings against the project's vulnerability database. New findings are displayed as a diff in the merge request security widget, showing vulnerabilities introduced by the current changes versus the target branch. Existing known vulnerabilities can be dismissed, confirmed, or resolved through the vulnerability management interface. The security dashboard at the group and instance level aggregates vulnerabilities across all projects, giving security teams a centralized view.
In production, a team building banking-portal would enable the full scanning suite. SAST catches SQL injection, XSS, and insecure deserialization patterns in the source code during every merge request. Dependency scanning flags when a library like log4j has a known CVE, linking to the advisory and suggesting the patched version. Container scanning runs after the Docker image is built, identifying vulnerable OS packages in the base image. Secret detection prevents developers from accidentally committing AWS keys or database passwords. DAST runs against the review app deployed for the merge request, testing the running application for OWASP Top 10 vulnerabilities. The team configures vulnerability policies requiring that critical and high severity findings must be resolved before merging, while medium findings are tracked but do not block the pipeline. Security findings are automatically created as issues with the vulnerability label, and the security dashboard provides compliance reporting for auditors.
A key gotcha is that security scanning templates can significantly increase pipeline duration. SAST and dependency scanning are relatively fast (2-5 minutes), but DAST can take 30-60 minutes for a full scan. Mitigate this by running DAST only on merge requests targeting the default branch or on a scheduled nightly pipeline, not on every commit. Another common issue is false positives: scanners may flag code patterns that look vulnerable but are actually safe in context. GitLab allows you to dismiss false positives with a reason, and the dismissal persists across pipelines so you are not re-alerted. Always review the SAST configuration to exclude test files and generated code that produce noise.