SAST, Dependency Scanning, Secret Detection, Container Scanning, DAST, IaC Scanning, and Security Gates: Configuration, Design Choices, and Tradeoffs

1. Built-in GitLab scanners versus external tools

Whatever scanner ownership model you choose, the evidence contract still begins with CI_PIPELINE_SOURCE and CI_COMMIT_SHA; template/component choice must not break source provenance.

2. Advisory scan versus enforced gate

An advisory scan produces evidence and keeps development moving. A gate blocks when a documented condition is met. Neither is universally correct. Early rollout often starts advisory to measure noise and coverage, then graduates to a gate with known ownership and exception handling.

3. Stable versus Latest templates and components

Current GitLab guidance recommends Stable security templates for production workflows because breaking changes are constrained to major GitLab versions. Latest templates deliver newer behavior faster and can change between minor releases. Mixing Stable and Latest security templates in the same project can create duplicate branch/MR pipelines.

GitLab increasingly publishes official CI/CD components for security scanners. Treat component references as software dependencies: use a reviewed release/update policy. Examples in GitLab docs sometimes show @main for discovery, but a mutable branch is not an immutable production dependency.

4. Dependency Scanning migration: do not build new workflows around the deprecated path

Current GitLab Dependency Scanning is Ultimate and is moving to the SBOM-based analyzer. The migration guide says the legacy Gemnasium-based scanning feature was deprecated in 17.9 and is proposed for removal in GitLab 20.0. Stable/latest template users should migrate to Jobs/Dependency-Scanning.v2.gitlab-ci.yml; component users should use major version 2 of the main dependency-scanning component.

For this course's Free mandatory path, Chapter 26 will build supply-chain evidence directly from SBOM/dependency artifacts and local tooling. That preserves the mental model without pretending the paid GitLab workflow is available.

5. False positives and exceptions are governed evidence

A false positive is not “a finding somebody dislikes.” Triage should capture the finding identity, source/report SHA, technical rationale, reviewer/owner, scope, and expiry/review date. If the finding is accepted risk rather than false positive, say so explicitly. Suppression files should be version controlled and narrowly scoped.

{
  "finding_id": "synthetic-secret:8b2f6d4e",
  "classification": "training_marker_false_positive",
  "scope": "src/app.py:LAB_SECRET_EXAMPLE_NOT_CREDENTIAL",
  "owner": "lab-security-reviewer",
  "rationale": "Synthetic marker contains no credential material.",
  "expires": "2026-09-30"
}

6. Broad scan coverage versus feedback latency

Run fast source/secret/IaC scans in merge-request feedback when they fit runner capacity. More expensive dependency resolution, container scans, or DAST may use staged pipelines or scheduled/release checks depending on risk. Do not improve latency by silently dropping scanner classes. Record which checks were omitted and why.

Chapter 17's fan-out lesson applies: parallelize independent scans only within runner capacity. Chapter 18's cancellation lesson also applies: safe read-only scans can often be interruptible; deployment or external active-scanning side effects need different treatment.

7. Identity design: CI_JOB_TOKEN, registry credentials, cloud identity, and scanner data

The scanner should receive only the identity needed to read its input. Source scanners usually need repository checkout, not cloud-admin access. Container scanners need pull access to the exact image, not push/delete permission. DAST should authenticate to a disposable test account if authentication is required. Cloud/IaC validation that requires live access should prefer short-lived federated identity rather than long-lived static secrets, and only when the scan scope genuinely requires provider access.

8. Decision table

Knowledge check

Official references and version notes

Documentation verification date: 2026-09-12. Basic GitLab SAST, pipeline Secret Detection, Container Scanning, and IaC scanning are documented for Free/Premium/Ultimate. Current GitLab Dependency Scanning and DAST are Ultimate. Security policy enforcement is Ultimate. GitLab's current Dependency Scanning direction is SBOM-based; the legacy Gemnasium-based implementation was deprecated in GitLab 17.9 and is proposed for removal in GitLab 20.0. Stable security templates are recommended for production workflows; Latest templates change more frequently. AST_ENABLE_MR_PIPELINES="true" is the current recommended switch for supported application-security scans in merge-request pipelines. GitLab documents Stable and Latest security template editions and warns against mixing editions. Current Dependency Scanning migration guidance specifically moves projects to the v2 SBOM-based analyzer/template/component path.

• SAST — official reference.
• SAST analyzers — official reference.
• Secret detection — official reference.
• Secret detection configuration — official reference.
• Container scanning — official reference.
• Dependency scanning — official reference.
• Dependency scanning migration to SBOM — official reference.
• DAST — official reference.
• DAST browser analyzer — official reference.
• IaC scanning — official reference.
• Security configuration — official reference.
• Security policies — official reference.
• Security scanner integration and report schemas — official reference.
• CI/CD YAML syntax — official reference.

Current assumptions used in this chapter: Version-sensitive YAML, Runner/executor behavior, APIs, security features, policy controls, tiers, and deprecations must be verified against the exact GitLab, GitLab Runner, tool, and external-system versions used in production. Preserve the exact project/ref/SHA, compiled configuration, pipeline/job IDs, runner/tool versions, and external target evidence used for reproducible work.