Practice: run and inspect security scans

Security Templates

A green pipeline does not prove that a security scanner ran. The job logs and report artifacts show what was scanned and what was found.

Run SAST and secret detection

Use a separate, cloned practice project with permission to push and a Linux AMD64 runner using the Docker or Kubernetes executor. Create app.py with this Python input for SAST:

print("Security scan practice")

Create .gitlab-ci.yml with this complete configuration:

stages:
  - test

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  1. Commit and push both files to a branch. Open the resulting branch pipeline.
  2. Open semgrep-sast and secret_detection. Check their logs for completed scans.
  3. Download gl-sast-report.json and gl-secret-detection-report.json from the respective job artifacts. Identify the scanner and the findings in each report. Security UI views depend on the GitLab license; use the JSON reports for this exercise.
  4. Note one finding and its file path, or note that the scan completed without findings. Never commit real credentials as test data.

Expected result: two completed scans with downloadable reports. This minimal input can produce no findings. If a job is missing, check runner availability, supported files, and job rules.

Add dependency scanning, optional

Before starting, confirm that the instance has GitLab Ultimate, synchronized package metadata, and the v2 template. Use an application with a supported lockfile or dependency graph . Skip this extension if these prerequisites are unavailable.

Replace the include list with:

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml
  1. Push the application files and configuration. With an open Merge Request, inspect dependency-scanning in the MR pipeline and the other two scans in the branch pipeline. Without an open MR, inspect the branch pipeline.
  2. Download gl-sbom-*.cdx.json and gl-dependency-scanning-report.json from dependency-scanning. Identify one component and its version in the SBOM, then inspect the vulnerability report.

Expected result: a component inventory and a dependency scanning report. A successful job without these reports does not meet the goal.

See GitLab’s SAST , secret detection , and dependency scanning documentation for configuration details.

Verify both the analyzer’s execution and its report. No findings does not guarantee that the application has no vulnerabilities.

Check

Suggested answer
No. The exercise requires the Python analyzer to run and produce its report. Check the source files, runner, job rules, and pipeline type.
Suggested answer
No. Scans depend on supported input files, licensing, and pipeline execution. Auto DevOps also requires a runner capable of running Docker in privileged mode. A failed build can prevent later security jobs from running. Check the Auto DevOps requirements before using it.