SAST, Dependency Scanning, Secret Detection, Container Scanning, DAST, IaC Scanning, and Security Gates: Concepts, Architecture, and Mental Model

1. The practical problem: “the security job passed” is not a security conclusion

Chapter 24 treated test and quality reports as evidence rather than as magic widgets. Security scanning needs the same discipline, with an additional complication: each scanner sees a different input and threat model. A SAST analyzer can report no source-code weakness while a vulnerable dependency remains. A dependency scanner can be clean while a secret is committed. A container scan can be clean while the running service exposes an insecure endpoint. A DAST result can be technically correct but operationally unacceptable if the target was production.

This chapter therefore treats a security pipeline as an evidence-producing control, not as a green shield icon. The scanner must be identified, its input bounded, its report preserved, its findings interpreted, and any blocking policy made explicit. Exceptions need an owner, rationale, and expiry rather than an invisible bypass.

2. Scanner classes before configuration

3. Mental model: input → scanner → report → finding → policy → proof

The left side of the chain is technical detection; the right side is governance. The scanner reads an exact target with an exact engine/ruleset version. It emits a report. GitLab or another parser ingests that report. A policy may then classify or gate findings. The remediation is a new change that must be rescanned; dismissing or excepting a finding is not the same as fixing it.

4. Current GitLab availability: scanner execution is not the same as security management

Tier availability can differ between running a scanner and viewing/managing findings in merge-request or vulnerability-management UI. Always verify the current feature page for the exact workflow you intend to rely on.

5. Version and template identity are security evidence

GitLab-managed analyzers are container images and their detection behavior changes over time. Stable security templates are designed for production stability; Latest templates can change between minor GitLab versions and should not be mixed with Stable templates in the same project. GitLab also publishes CI/CD components for several security scanners, but a component reference such as @main is a moving reference. Production reuse should have an explicit update policy rather than silently following mutable configuration.

Dependency Scanning deserves special attention. Current docs recommend the SBOM-based path. The legacy Gemnasium-based implementation was deprecated in GitLab 17.9 and is proposed for removal in GitLab 20.0. The migration guide directs stable/latest template users to the v2 dependency-scanning template and component users to major version 2 of the main component.

6. A security report has a schema, not just JSON syntax

A custom scanner integration must emit a GitLab-supported security-report schema. Valid JSON is insufficient. GitLab validates the declared report schema; invalid reports are not ingested, deprecated schemas can warn, and removed schema versions are rejected. For local/external scanner labs in this chapter, raw scanner JSON is preserved as a normal artifact unless the tool is deliberately adapted to a valid GitLab schema.

This distinction prevents a common teaching error: relabeling arbitrary Semgrep, Trivy, or custom JSON as artifacts:reports:sast. A report becomes a GitLab security report only when its schema and category contract are correct.

7. Read-only inspection before any repair

printf 'source=%s ref=%s sha=%s pipeline=%s job=%s\n' \
  "$CI_PIPELINE_SOURCE" "$CI_COMMIT_REF_NAME" "$CI_COMMIT_SHA" \
  "$CI_PIPELINE_ID" "$CI_JOB_ID"

# Record scanner/report evidence without printing secret-bearing variables.
find security-reports -maxdepth 1 -type f -print 2>/dev/null || true
sha256sum security-reports/* 2>/dev/null || true

# Inspect versions through the tool itself, not by guessing an image tag.
semgrep --version 2>/dev/null || true
trivy --version 2>/dev/null || true

8. Trust boundary: scanning untrusted code does not justify privileged credentials

Security scanners often execute against merge-request content, containers, or URLs. That does not make the input trusted. A fork or untrusted branch should not receive production secrets, cloud-admin credentials, a privileged runner, or a route to production simply because the job is named “security.” DAST is especially sensitive: GitLab documentation explicitly advises running DAST against a test server. If a target cannot be proven disposable/authorized, do not scan it.

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. SAST and IaC scanner jobs require supported Linux runner/executor/architecture conditions in GitLab-managed paths; DAST requires a running authorized test target. Recheck analyzer prerequisites before production rollout.

• 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.