# GitLab DevSecOps Part 5: Static Application Security Testing (SAST) > Part 5 of the GitLab DevSecOps series. Patrick Steger and I add Static Application Security Testing (SAST) to the GitLab pipeline using GitLab's managed template, which runs Semgrep and SpotBugs against our Java code and surfaces vulnerabilities like predictable random number generators directly in GitLab. - Date: 2022-08-31 - Source: https://romanoroth.com/en/blogs/gitlab-devsecops-sast/ - Tags: DevSecOps, GitLab, CI/CD, DevOps, SAST, Static Application Security Testing, Application Security, Semgrep, SpotBugs 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.