SAST & code scanning

Find bugs in your own source.

Static Application Security Testing (SAST) reads your source code without running it and flags likely vulnerabilities — SQL injection, hardcoded credentials, unsafe deserialization, path traversal. It runs early in the pipeline (the code is right there, no deploy needed) and it is the first scanning stage to add because it finds bugs you wrote, in code you can fix immediately. GitLab ships a built-in SAST template; Semgrep and CodeQL are the common standalone engines.

include:
  - template: Jobs/SAST.gitlab-ci.yml   # GitLab’s built-in SAST
 
# or a standalone engine you control:
semgrep:
  stage: test
  image: returntocorp/semgrep
  script: [semgrep ci --config auto]     # findings surface in the MR

Tune it or lose it

A SAST tool out of the box is noisy — false positives train developers to ignore it, and an ignored scanner is worse than none. The skill is tuning: start in report-only mode so nothing blocks, triage the findings, suppress the confirmed false positives with inline annotations, and only then gate the merge on real, high-confidence categories. A scanner developers trust is one they keep enabled.

Where SAST fits among the scanners

SAST is one of a family, and it helps to know its lane: SAST reads your code, secret detection reads your commits for credentials, dependency scanning reads your libraries for known CVEs, image scanning reads the built container, and DAST tests the running app. Each finds a different class of problem, and a complete pipeline runs all of them. SAST’s niche is flaws in the logic you wrote — the ones only your source reveals.