↓ Skip to main content
Romano Roth
GitLab DevSecOps Part 5: Static Application Security Testing (SAST)
  1. Blogs/

GitLab DevSecOps Part 5: Static Application Security Testing (SAST)

·4 mins
DevSecOps GitLab CI/CD DevOps SAST Static Application Security Testing Application Security Semgrep SpotBugs
Author
Romano Roth
I believe the next competitive edge isn’t AI itself, it’s the organisation around it. As Chief AI Officer at Zühlke, I work with C-level leaders to build enterprises that sense, decide, and adapt continuously. 20+ years turning this conviction into practice.
Table of Contents
Ask AI about this article

Software composition analysis takes care of the libraries you pull in. But what about the code your own team writes? That is where Static Application Security Testing comes in. In Part 5 of our GitLab DevSecOps series, Patrick Steger and I add SAST to the pipeline, plant a few realistic vulnerabilities in our Spring Boot sample, and watch GitLab pick them up.

What SAST Actually Does
#

SAST scans your source code for security vulnerabilities without running the application. Patrick gives the classic example: cryptography. If you reach for a weak cipher, or use the regular Random class to generate something that should be unpredictable, that is a security flaw — and it is the kind of thing a static analyzer can spot by reading the code.

GitLab’s SAST primarily uses Semgrep, an open-source pattern-based scanner. Depending on the language, it may pull in additional tools too. For our Java sample, Semgrep is paired with SpotBugs. Each tool has its own strengths and weaknesses; combining them widens coverage.

Wiring SAST into the Pipeline
#

The mechanic is the same as everything else we have added so far. We open .gitlab-ci.yml, add one include line that references GitLab’s managed SAST.gitlab-ci.yml template, commit to master, and the pipeline takes it from there.

Before we add the line, Patrick simplifies the Spring Boot main app and drops in a new controller with deliberate problems. The one we expect SAST to flag sits on line 47: an insecure java.util.Random used where SecureRandom belongs. A predictable pseudorandom generator wherever cryptographic keys or tokens are involved is exactly the kind of finding SAST is supposed to surface.

Two Tools Under the Hood
#

Open the managed template and search for Java, and you see GitLab orchestrates two scanners: Semgrep and SpotBugs. The pipeline grows two new jobs accordingly — semgrep-sast and spotbugs-sast. Click into either one and the log shows the same recipe we have seen before: pull a Docker image, run the scanner, upload findings to GitLab’s vulnerability system.

The job logs themselves are not where you read the results. They are noisy and not designed for humans. The real surface is the Security tab on the pipeline, with a SAST filter. There, our predictable pseudorandom finding shows up exactly where we expected it, with a direct link into the source file at line 47.

Where the Findings Live
#

GitLab gives you two views of vulnerabilities. The pipeline’s Security tab shows what this run found. The Security & Compliance → Vulnerability Report under the project gives you the governance view — everything across pipelines, with filters and triage. That governance view requires the Ultimate edition. Running the SAST scanners themselves is part of the free license. Worth knowing before anyone signs a contract based on screenshots.

What This Buys You
#

One include line gave us two scanners, two new pipeline jobs, automatic vulnerability uploads, and a clean UI to triage findings. Compared to wiring this together by hand on another platform, that is genuinely cheap. The trade-off is that you accept GitLab’s choices about which tools to run and which rules to enable. For most teams, that is the right trade — start with the managed template, and only invest in custom rules or extra scanners once you can prove the defaults are missing things you care about.

Key Takeaways
#

  1. SAST scans code you wrote, not dependencies. SCA covers third-party libraries; SAST is about your own source. Both belong in CI, and they answer different questions.

  2. One include line buys two scanners. GitLab’s managed SAST.gitlab-ci.yml template wires up Semgrep plus, for Java, SpotBugs. You do not have to choose tools, install them, or maintain Docker images.

  3. Combining scanners improves coverage. Each tool has different strengths. Running Semgrep and SpotBugs together catches more than either one alone — and you get that for free with the managed template.

  4. Read findings in the Security tab, not the job log. The pipeline log shows that the scanner ran. The actual vulnerabilities live under the pipeline’s Security tab, with deep links into the offending code.

  5. Random instead of SecureRandom is exactly the kind of bug SAST catches. Predictable pseudorandom generators used for security-relevant values are a textbook static-analysis finding. If your team writes any cryptographic or auth code, this alone justifies the few minutes it takes to enable SAST.

  6. Scanning is free; governance is Ultimate. The SAST scanners run on the free tier. The cross-pipeline Vulnerability Report under Security & Compliance requires the Ultimate edition. Plan your tier accordingly — do not assume the dashboards in screenshots come with the free plan.