GitLab CI security scanners: SAST, DAST, secrets and dependencies

Your pipeline builds, tests and deploys, but an npm dependency contains a critical CVE (a known vulnerability, publicly listed under a unique identifier), a developer committed an AWS token, and your Docker image ships a vulnerable OpenSSL. You will only find out after the incident. GitLab builds five security scanners straight into CI/CD: they analyze your code, your dependencies, your images and your secrets on every pipeline, with a vulnerability report that developers can act on.

Each one covers a family of risks: SAST analyzes the source code without running it, Secret Detection spots committed tokens, API keys and passwords, Dependency Scanning looks for known CVEs in the libraries the project depends on, Container Scanning inspects the Docker images you build, and DAST tests the deployed application the way an external attacker would. Each scanner has its own section below.

Branch pipelines vs merge request pipelines. By default, the scanners run on branch pipelines (on every push). To run them specifically on merge request pipelines and show the vulnerability diff, add the variable SAST_ENABLE_MR_PIPELINES: "true" (and its equivalent for each scanner) or use the latest templates (Jobs/SAST.latest.gitlab-ci.yml).

What you will learn

• Enable each scanner in a GitLab CI pipeline with the official templates
• Read a vulnerability report in a merge request and prioritize the fixes
• Configure Secret Detection to detect committed tokens before the merge
• Scan your Docker images built in the same pipeline
• Configure the governance mechanisms to react to detected vulnerabilities
• Choose between Auto DevOps and manual configuration

In which context?

The GitLab security scanners meet a precise need: detect vulnerabilities as early as possible in the development cycle, ideally at the merge request, before the code reaches the main branch.

Without these scanners, teams discover security problems:

• In production, when an external scanner (Trivy, Snyk) detects a critical CVE on a deployed image
• During an audit, when they find that secrets have been lying in the Git history for months
• After an incident, when an attacker exploits a dependency vulnerability that had been known for a long time

In daily practice, the scanners are used to:

• Catch secrets (AWS tokens, SSH keys, passwords) in commits before they are merged into the main branch
• Check dependencies on every update of package-lock.json, go.sum or requirements.txt
• Validate Docker images before pushing them to the Container Registry
• Test the attack surface of an application deployed in a review app
• Produce reports for compliance audits (see Audit & compliance)

Prerequisites

• A GitLab project with a working pipeline (see First pipeline)
• Understand templates and includes (the scanners use include: template:)
• For Container Scanning: a job that builds a Docker image (see Registries)
• For DAST: a deployed application that is reachable (review app or staging environment)

Availability by GitLab tier

Which column applies to your instance? The columns below are tiers (subscription levels), not software editions. A self-managed GitLab Community Edition (CE) instance falls under the Free tier: the "Free" column is the one that concerns you. To reach Premium or Ultimate, GitLab requires you to convert the instance to Enterprise Edition (EE) and then activate a subscription: CE cannot take a licence. Conversely, Free is not reserved to CE, because the EE package run without a licence also offers the Free features. This page has not replayed each scanner on a CE instance: it relies on what the GitLab documentation declares for the Free tier.

Running the scan (downloadable JSON report):

Scanner	Free	Premium	Ultimate
SAST	Yes	Yes	Yes
Secret Detection	Yes	Yes	Yes
Container Scanning	Yes	Yes	Yes
Dependency Scanning	No	No	Yes
DAST	No	No	Yes

Swipe to see more

Advanced features (Ultimate only):

• Security widget in the merge request (newly detected vulnerabilities)
• Centralized Vulnerability Report and vulnerability management
• Merge request approval policies (blocking on findings)
• Security Dashboard
• Rule customization (SAST and Secret Detection) and UI-based SAST configuration
• GitLab Advanced SAST (cross-file analysis)
• Container Scanning: report display in the MR, automatic remediation solutions, vulnerability allow list, dependency list page
• Secret Push Protection

On the Free tier (so on a CE instance, see above), you can run SAST, Secret Detection and Container Scanning and download the JSON reports. Viewing them in MRs and managing vulnerabilities require Ultimate. Dependency Scanning and DAST are Ultimate as a whole: the GitLab documentation marks them Tier: Ultimate.

The 5 scanners explained

Overview

Source code ──► SAST ──────────► Vulnerabilities in the code
     │
     ├──► Secret Detection ──► Tokens/keys detected
     │
     ├──► Dependency Scanning ► CVEs in the dependencies
     │
     └──► Container Scanning ─► CVEs in the Docker image
                                       │
Deployed application ──► DAST ─────────► Web vulnerabilities (XSS, injection, etc.)

SAST, Static Application Security Testing

SAST analyzes your source code without running it. It detects programming flaws: SQL injections, XSS, use of dangerous functions, poor handling of user input.

GitLab automatically detects the languages and enables the matching analyzers. Depending on the project, several analyzers can run in parallel: Semgrep (Python, JS, Go, Java…), SpotBugs (Java, Kotlin), Sobelow (Elixir), PMD (Apex), Kubesec (Kubernetes manifests) and GitLab Advanced SAST (Ultimate, inter-procedural analysis).

include:
  - template: Jobs/SAST.gitlab-ci.yml

That's it. GitLab automatically creates one or more jobs (e.g. semgrep-sast, spotbugs-sast) in the test stage which:

1. Detect the project's languages
2. Run the appropriate analyzers
3. Produce a gl-sast-report.json report (GitLab Security Report format, not SARIF)
4. Show the results in the merge request (Ultimate)

Common customization:

include:
  - template: Jobs/SAST.gitlab-ci.yml

variables:
  SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,vendor,node_modules"
  SEARCH_MAX_DEPTH: 4

Secret Detection

The Secret Detection scanner goes through the commits to find secrets (tokens, API keys, passwords, certificates) that should not have been committed.

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

Among other things, it detects:

Type of secret	Example pattern
AWS keys	AKIA[0-9A-Z]{16}
GitLab tokens	glpat-[0-9a-zA-Z_-]{20}
SSH/RSA private keys	-----BEGIN RSA PRIVATE KEY-----
GitHub tokens	ghp_[0-9a-zA-Z]{36}
Clear-text passwords	Variables containing password, secret, token

Swipe to see more

A committed secret cannot be uncommitted

Even if you delete the file containing the secret, it stays in the Git history. The only reliable solution is to revoke the secret and generate a new one. The Secret Detection pipeline alerts you after the push, before the merge to limit the exposure. To refuse the push before GitLab records the commits, GitLab offers Secret Push Protection: a separate feature, run server-side in the pre-receive hook, enabled in the project's Secure > Security configuration. It is reserved to GitLab Ultimate: a CE instance does not offer it.

Initial scan of the history (run only once):

After enabling Secret Detection, run a pipeline manually with the variable SECRET_DETECTION_HISTORIC_SCAN: "true" to scan the whole Git history. It is a one-shot scan, do not leave it in your permanent configuration, because it makes every pipeline considerably longer.

# Single manual pipeline for the historic scan
# Build > Pipelines > New pipeline > Add variable:
#   SECRET_DETECTION_HISTORIC_SCAN = true

Standard (daily) configuration:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

variables:
  SECRET_DETECTION_EXCLUDED_PATHS: "tests/"

Dependency Scanning

Dependency Scanning analyzes your lock files (package-lock.json, go.sum, Gemfile.lock, requirements.txt) to identify the dependencies with known CVEs (NVD database and GitLab Advisory Database).

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

It produces a report listing each vulnerable dependency with:

• The CVE identifier
• The severity (Critical, High, Medium, Low)
• The fixed version (when there is one)
• The link to the advisory

Customization:

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

variables:
  DS_EXCLUDED_PATHS: "vendor/"

Container Scanning

Container Scanning analyzes the Docker image that your pipeline has just built to find vulnerabilities in the system packages (apt, apk, rpm) and the embedded libraries.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

Link with the Registries guide

Container Scanning fits naturally with the Container Registry: you build the image in a build job, push it to the registry, then the scanner analyzes it in a following job using the same reference $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA.

DAST, Dynamic Application Security Testing

DAST tests an application that is deployed and reachable by simulating real attacks: SQL injections, XSS, CSRF, missing security headers, etc.

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_TARGET_URL: "https://staging.mon-app.com"

The dast stage is required

The DAST template puts the job in the dast stage. You must add this stage to your stages: list. Otherwise GitLab rejects the whole configuration, including jobs that come from an include: the pipeline is born failed with no job at all, the other scanners do not run either, and the interface does not say why. Only the project's CI linter (the validation tab of the pipeline editor) names the cause: chosen stage dast does not exist.

DAST is the heaviest scanner: it launches a headless browser and explores the application. It is generally run on a staging environment or a review app, not in production.

Customization:

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_TARGET_URL: "https://$CI_ENVIRONMENT_SLUG.review.mon-app.com"
  DAST_FULL_SCAN_ENABLED: "false"  # Quick scan by default
  DAST_BROWSER_SCAN: "true"        # Browser-based scan (recommended)

Complete security pipeline

Here is a pipeline that combines the 5 scanners with the build and test steps:

stages:
  - build
  - test
  - deploy
  - dast  # Stage required by the DAST template

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Container-Scanning.gitlab-ci.yml
  - template: Security/DAST.gitlab-ci.yml

variables:
  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  DAST_TARGET_URL: "https://$CI_ENVIRONMENT_SLUG.staging.mon-app.com"

build-image:
  stage: build
  image: docker:27@sha256:aa3df78ecf320f5fafdce71c659f1629e96e9de0968305fe1de670e0ca9176ce
  services:
    - docker:27-dind@sha256:aa3df78ecf320f5fafdce71c659f1629e96e9de0968305fe1de670e0ca9176ce
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"

test:
  stage: test
  image: node:22-alpine@sha256:16e22a550f3863206a3f701448c45f7912c6896a62de43add43bb9c86130c3e2
  script:
    - npm ci
    - npm test

deploy-staging:
  stage: deploy
  script:
    - deploy-to-staging.sh
  environment:
    name: staging/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.staging.mon-app.com
  rules:
    - if: $CI_MERGE_REQUEST_IID

The build-image job reads the registry password on standard input with --password-stdin, rather than in a -p argument: a command-line argument shows up in the process list (ps) and can end up in the job traces.

Execution order

The GitLab templates automatically put the scanners in the test stage. In the pipeline above, build-image is in the build stage, which comes before test: Container Scanning therefore starts after the image is published, and there is nothing to add.

The advice applies only if your build job is in the same stage as the scan: the jobs of one stage run in parallel. In that case, either you place the scan in a later stage, or you declare a needs: pointing to the build job, which requires it to finish before the scan.

Reading the vulnerability reports

In the merge request

When the scanners run on an MR, GitLab shows a security widget summarizing:

• The number of new vulnerabilities introduced by the MR
• The number of vulnerabilities fixed
• The breakdown by severity (Critical, High, Medium, Low)

Each vulnerability is clickable and displays:

• The description of the flaw
• The file and line concerned (SAST) or the dependency (Dependency Scanning)
• The severity and the CVSS score
• The recommended solution (update, workaround)
• The CVE / CWE identifier

In the Security Dashboard

The Security Dashboard (Security & Compliance > Vulnerability Report) centralizes all the vulnerabilities detected on the default branch. It lets you:

• Filter by scanner, severity, status
• Mark a vulnerability as "confirmed", "dismissed" or "resolved"
• Create a GitLab issue directly from a vulnerability
• Track the evolution over time

First governance mechanisms

Two complementary mechanisms let you react to the scanners' results:

1. allow_failure: false, detect scanner failures

By default, the scanners use allow_failure: true: if the scanner crashes (timeout, network error, image unavailable), the pipeline continues. By switching to false, a failure of the scanner itself blocks the pipeline, but the vulnerabilities detected block nothing:

semgrep-sast:
  allow_failure: false  # Blocks if the scanner crashes, NOT if findings exist

allow_failure does not block on findings

allow_failure: false guarantees that the scanner runs correctly, not that it finds nothing. A scan that detects 50 critical vulnerabilities remains a successful scan (exit code 0). To block on the results, use the merge request approval policies below.

2. Merge request approval policies, block on findings (Ultimate)

To prevent the merge when critical vulnerabilities are detected, configure a merge request approval policy in a security policy project:

1. Create a Security Policy Project (Security & Compliance > Policies > New policy project)

2. Create a Merge request approval policy with a scan_finding rule:

   • Minimum severity: critical or high
   • Scanners concerned: SAST, Dependency Scanning, Container Scanning, Secret Detection
   • Required approvers: members of the security team

3. Link the policy project to your projects (Settings > Security & Compliance > Security policy project)

Ultimate required

Merge request approval policies require GitLab Ultimate. On the Free and Premium tiers, you can use allow_failure: false and classic manual approval rules, but without automatic blocking on findings.

Auto DevOps vs manual configuration

GitLab offers Auto DevOps, which automatically enables all the scanners without configuration. It is tempting, but here is when to choose each approach:

Criterion	Auto DevOps	Manual configuration
Setup time	Instant	15 min
Control	Limited	Total
Scanners enabled	All	Your choice
Customization	Via variables	Via full YAML
Recommended for	Prototyping, small projects	Production, compliance

Swipe to see more

To enable Auto DevOps: Settings > CI/CD > Auto DevOps > Enable.

For most teams in production, manual configuration via include: template: is preferable because it gives explicit control over what runs.

Troubleshooting

Symptom	Likely cause	Solution
Scanner not run	Template not included, or template rules that exclude the job	Check include: and the template variables
Pipeline failed with no job at all, no message	A job (even one from an include) uses a stage missing from stages:	Open the project's CI linter: it names the missing stage
SAST: 0 findings on a project with code	Language not detected	Add SAST_DEFAULT_ANALYZERS explicitly
Container Scanning fails	Image not found	Check CS_IMAGE and that the build job succeeded
Secret Detection: false positives	Pattern too broad	Add a .gitlab-secret-detection.toml file to exclude
DAST timeout	Application not reachable from the runner	Check the URL and the runner's network
Security widget missing in the MR	Insufficient license or missing reports	Check the GitLab tier and the jobs' artifacts
Dependency Scanning: 0 findings	Lock file missing	Generate package-lock.json or go.sum beforehand

Swipe to see more

Hands-on lab

The lab "Turn the scanners on, and read what they say" replays this guide on a GitLab CE forge set up on a virtual machine, with its runner and its registry. The project's pipeline only runs the application tests: it is green, and nobody has ever looked at what the repository holds from a security point of view. You enable two of the three scanners available on the Free tier, SAST and Secret Detection, with the same include: template: lines as above.

Because the lab instance runs Community Edition, it has no Security Dashboard and no security widget in the merge request: the report is a JSON file dropped as an artifact (gl-sast-report.json, gl-secret-detection-report.json), and reading it is part of the job. A committed token has been sitting in the code for a long time, which calls for the historic scan described above, run once by hand. You fix the flaw the report points at, then record in a LECTURE.md file the file and the line it named.

Grading is taken on what the forge really produced: two successful jobs that dropped a readable report, a report that names the token, and a fresh scan on main that no longer names it while the tests still pass. Deleting the line without running the scanner is therefore not enough. The lab starts with dsoxlab run gl-21-activer-les-scanners, after dsoxlab provision; installing DSOXLab is described in the DSOXLab documentation.

Guided lab Practice

Learn how to do it

Turn the scanners on, and read what they say

$ dsoxlab run gl-21-activer-les-scanners

Environment: VM·Duration: ~40 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start gl-21-activer-les-scanners checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/gitlab-ci-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run gl-21-activer-les-scanners
dsoxlab check gl-21-activer-les-scanners

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key takeaways

• GitLab builds in 5 security scanners that you enable via include: template:, no external tools needed
• SAST, Secret Detection and Container Scanning are available on all tiers (including Free, the tier of a CE instance), Dependency Scanning and DAST require Ultimate
• Results appear directly in the merge request (Ultimate widget), on Free, the JSON reports can be downloaded
• Container Scanning analyzes the Docker images built in the same pipeline
• DAST tests the deployed application, it needs a reachable environment and the dast stage
• allow_failure: false detects scanner failures, to block on findings, configure merge request approval policies (Ultimate)
• Auto DevOps enables everything automatically, but manual configuration offers more control
• These scanners complement the level 4 security module, which covers protecting the pipelines themselves

Knowledge check

Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →