DevSecOps Series III - SAST

April 8, 2025 // echel0n

Hello guys! As I promised before, this is the third blog of DevSecOps Series! In this blog, I will give some details about what SAST is and why we should use it. Plus, I will provide an example of a local deployment of SonarQube CE. Hope you will enjoy it!

Table of Contents

SAST - Static Application Security Testing
The Action - Installation of SonarQube
The End - Conclusion

0 Used Tools, Tested Hardware/Software and Warnings

Some configurations here and in the repository I referenced may be insecure, and it is recommended that you act with awareness. Since this is a lab environment, we will not be making many security configurations of the tools.

These are the tools we will be setting up. (Check previous blogs if something is missing!)

SonarQube CE as a SAST solution

Provided configurations are tested in this hardware and software;

CPU: AMD Ryzen 9 5900X (24) @ 5.619GHz 
Memory: 23904MiB 
Swap: 4GB 
OS: ArchLinux 6.13.8-zen1-1-zen
Terminal: 5.2.37 
Docker version 27.3.1, build ce1223035a 
k3s version v1.31.3+k3s1 (6e6af988)
go version go1.22.8

This setup is using a lot of resources. Be careful after deploying the tools, as they can quickly exhaust your resources. Do not forget to save your critical data while the instances are running. I am pretty new to Kubernetes so I am open to fine-tuning suggestions, please feel free to get in touch, it would be great to learn more!

1 SAST - Static Application Security Testing

1.1 What is SAST?

Static application security testing sounds like a new term or a new way to feel more secure but it is well-known technique (static program analysis) since late 90s, dot-com bubble.

Unlike other security tests, this step focuses on the code-base directly, not directly application functionality. Basically, examines the text of a program syntactically and looks for fixed set of patterns and rules in the code-base. This can also mean, it's a "pay-to-win" game. Mostly, these fixed set of patterns and rules are being handed to you by vendors. So, you are usually stuck with those configurations. Like in most p2w games, "creating your rules and patterns" option is also available but it is expensive tho. I think that most organizations have not even tried once to write their custom configurations at all. Fortunately, the out-of-the-box rules and patterns of well-known vendors are just "fine".

1.2 How?

These aforementioned rules are being written for; sequences of instructions and flow of the data. Unlike us, the SAST solutions are reading the codebase with a data structure known as abstract syntax tree(AST). Once AST is built, you are ready to explore the flow of data across the code-base. Does it sound like it is very simple? You are free to build your static analyzer with ANTLR for your favorite programming language if you would like to try. Let the Data-Flow Graphs guide you!

1.3 Really? Is it just AST then? So explain th...

No, not at all. It goes beyond, including some regular expression match in repositories' files. Of course, there are other components of a repository that do not contain code or cannot be represented in AST.

1.4 Basic mind-set of Review of SAST Findings

As a DevSecOps Engineer, most of the time, you will be reviewing these findings -so-called vulnerabilities- a lot. To review more structured, you should form this mindset with these definitions; (oversimplified analysis steps)

Tainted data (external data)
Source of tainted data (the first function that intruduces the tainted data)
A function that tainted data can potentially damage with it (sink)
Data validation where and how (sanitization)

This categorization will help you to track the steps of how vulnerability occurs, where it comes from, how it should be handled.

1.4 Some Caveats

1.4.1 False Positives and Alert Fatigue

FALSE POSITIVES! AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHH.

You will be dealing with a lot of false positives! I mean a lot! These false positives can harm your security perspective, overwhelm you to the point that the most dangerous findings will look like another false positive. So be warned!

1.4.2 Fine-Tuning of your daily routines

If your inventory expands daily or weekly, you will have some priorization problems. You may have difficulty reviewing the findings. After all, you are only single team of reviewers, there may be dozens of developers. These people will not wait much for the approval. (can I get a "HELL YEAH!" for AGILE development here?)

Also, SAST findings will not be the only one source for waiting to be reviewed. You will be doing already meetings and async discussions with the developer teams for open tickets and also will be reviewing other types of security scans that I will also explain them future blogs.

1.5 The Benefits

1.5.1 The earlier a vulnerability is fixed, the cheaper it gets.

1.5.2 Entire code-base is scanned, in theory, it can cover 100% of it, while DAST does not.

1.5.3 When it is integrated into CI/CD, it can stop the go-live process when some vulnerabilities are found.

2 The Action - Installation of SonarQube

Before applying SonarQube yaml file into our k3s, another database and its user creation are required. SonarQube is also using postgresql as a database backend. Happily, we have already installed it for JIRA deployment. We can start with creating user and its password and the database which will be used by SonarQube. Caution! If you would like to change these variables, please also change the definitions in "sonar-app.yaml" file too!

Also Install "SonarQube Scanner" Plugin into Jenkins

 Apply those sonar's yaml files. Then, get your access token from /account/security/  add into Jenkins Global Credentials from /manage/credentials

>

Add these lines into dvja's pipeline's configuration after Build stage then run. (or check out Jenkinsfile.sast file)

stage('SonarQube analysis') {
            steps {
                withSonarQubeEnv(credentialsId: "SONARQUBE_TOKEN", installationName: 'SonarQube') { // You can override the credential to be used, If you have configured more than one global server connection, you can specify the corresponding SonarQube installation name configured in Jenkins
                  sh '/var/jenkins_home/maven/apache-maven-4.0.0-beta-4/bin/mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.11.0.3922:sonar'
                }
            }
        }

Check the SonarQube dashboard for the results.

It reports security as A but It has found the SQL injection vulnerability too! (uhmm ok!?)

3 The End - Conclusion

DVJA is a vulnerable application as intended and its vulnerability is very easy to spot and test. We were able to find out vulnerability and the guilty lines which are responsible for it without any interaction. Wie cool ist das bitte?

Even though, we cannot find every lingering vulnerabilities in the code-base with it, SAST is a fundamental solution in our toolset to be more secure in such fast-pace development environments.

That is all for now! Thanks for finding my blog interesting enough to read. Have a nice day, you absolute legends! 🎉

References and Links

First Part - https://devilinside.me/blogs/devsecops-series-introduction
Second Part - https://devilinside.me/blogs/devsecops-series-simple-pipeline 
Provided Configurations and Scripts - https://github.com/echel0nn/devsecops-series