Why You Should Enable Both SAST and Dependency Scanning in GitLab CI/CD

Overview

Automated security scanning is a standard part of a CI/CD pipeline. GitLab provides two built‑in templates that can be added to a project’s .gitlab-ci.yml file: Security/SAST.gitlab-ci.yml and Jobs/Dependency-Scanning.gitlab-ci.yml. They address different attack surfaces and are intended to run together.

SAST – Static Application Security Testing

SAST analyzes the source code you write without executing the program. It parses the syntax tree, follows data‑flow and control‑flow paths, and looks for patterns that indicate insecure coding practices. Typical findings include:

SQL injection

Cross‑site scripting (XSS)

Unsafe deserialization

Hard‑coded secrets (often reported by the dedicated Secret Detection scanner)

Use of dangerous functions such as eval or system SAST therefore protects the quality of the custom code base – the “design blueprint” of the application.

Dependency Scanning

Dependency Scanning inspects the third‑party libraries and frameworks declared in manifest files such as package.json, pom.xml, or requirements.txt. The scanner extracts each dependency and its exact version, then compares the list against a continuously updated public vulnerability database (e.g., the CVE feed). Example findings are:

Remote code execution vulnerability in

some-lib

v1.2.3

Privilege‑escalation flaw in

cool-framework

v4.0

Dependency Scanning protects the “building materials” of the project – the external components that the code relies on.

Differences and Complementarity

SAST – focuses on the security of self‑written source code.

Dependency Scanning – focuses on known vulnerabilities in third‑party dependencies.

Because modern applications heavily depend on open‑source ecosystems, using only one of the scanners leaves a large attack surface uncovered. Running both provides depth‑in‑defense.

Implementation in GitLab CI

To enable the two scanners, add the following include entries to your project's .gitlab-ci.yml:

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

# Optional: customize variables
variables:
  SAST_EXCLUDED_ANALYZERS: "bandit,brakeman"   # example of disabling specific analyzers
  DEPENDENCY_SCANNING_DISABLED: "false"

Both jobs are executed in parallel as separate stages. Each job produces an artifact and a security report ( reports:sast and reports:dependency_scanning) that GitLab automatically attaches to the merge request. The merged view shows all findings in a single security dashboard, allowing developers and security teams to triage issues together.

Key Considerations

SAST requires language‑specific analyzers; ensure the language you use is supported by the GitLab SAST image.

Dependency Scanning relies on the freshness of the vulnerability database; keep the GitLab Runner up‑to‑date to receive the latest CVE data.

Both scanners add only a few seconds of pipeline time and no extra infrastructure, making the cost‑benefit ratio very high.

Illustrative Diagrams

The following images show how the two jobs fit into a typical CI pipeline and how their reports are aggregated.

Conclusion

Enabling both Security/SAST.gitlab-ci.yml and Jobs/Dependency-Scanning.gitlab-ci.yml is strongly recommended. They are independent, complementary scanners that together provide a comprehensive view of code‑level and supply‑chain risks with minimal configuration overhead.