GitLab security scanning

Secure.Your.Code!

…At all stages…Automatically…Always…Starting with the first line of your code…

Today, the security scanning of code, containers and applications is at least as important as the functionality of the application itself. It’s vital to detect software vulnerabilities like data leaks, secret publications (etc.) as early as possible during the software development lifecycle. Otherwise potential attackers will have an easy time exploiting your weak spots.

But what does that mean in the context of ever faster development processes, integrated CI/CD cycles and container orchestration software like Kubernetes?

Looking at the market of security scanning tools there are many but often complex ways to integrate third party security scanning tools into the development pipeline. If you are using GitLab as your version control system you can easily enable and maintain security scanning at all stages of the software development lifecycle. Additionally to those more technical topics GitLab allows you to manage any found vulnerability by its security and compliance boards next to the code base as well.

GitLab integrates security scanning smoothly

GitLab offers various security scanning technologies like

• Static Application Security Testing (All Tiers)
• Secret Detection Scanning (All Tiers)
• Dependency Checks (Ultimate Feature)
• Dynamic Application Security Testing (Ultimate Feature)
• Container Scanning (Ultimate Feature)
• License Scanning (Ultimate Feature)
• Vulnerability Report and Security Dashboard (Ultimate Feature)
• …

Get a full list of security scans provided by GitLab at Secure your application . For these different security scanning technologies GitLab supports a wide range of programming languages like Golang, Java, C/C++, python and many more to detect different kinds of vulnerabilities.

Small downside: To use GitLab’s complete list of security scanning tools you need to buy an “Ultimate” license. Since the Vulnerability Report is also an Ultimate Feature, security scans such as SAST or Secret Detection that are activated in the Free Tier can be executed but not visualised in the Vulnerability Report.

However the activation of security scans is very easy. Simply add the appropriate security scan template to your already existing gitlab-ci.yml file. Alternatively, if there has been no pipeline so far, create a new one inside your GitLab project. GitLab now is going to run these configured security scans during the next git push on that branch. The results appear on the security tab of the pipeline’s overview page.

Now we want to have a look at different types of security scanning methods:

1. Static Application Security Testing
2. Secret Detection
3. Dependency Checks

Furthermore, we will briefly look at how security issues can be managed in GitLab.

If you are interested in container or licence scanning or even dynamic scanning of applications, take a closer look at the second part of the article series GitLab security scanning – part 2 .

1) Static Application Security Testing (SAST)

SAST checks source code statically for known vulnerabilities and can be used at all tiers. To get a first idea of GitLab’s security scanning tools let us look at a very simple but vulnerable python script snippet:

1import subprocess
2
3# Vulnerable: read shell environment
4subprocess.call("echo $HOME", shell=True)
5
6# Vulnerable: print arbitrary files
7user_input = "foo && cat /etc/passwd"
8subprocess.call("grep -R {} .".format(user_input), shell=True)
9
10# Vulnerable: get shell access
11user_input = "echo "
12subprocess.run(["bash", "-c", user_input], shell=True)

All of these subprocess commands are vulnerable to user input because input values are passed to Python’s module function subprocess.call() directly without any sanitizing. This way, a potential attacker could access critical data.
Now enable SAST for that GitLab project by creating the following .gitlab-ci.yml file inside the project’s root directory:

1include:
2  - template: Security/SAST.gitlab-ci.yml

As soon as both files are pushed to remote repository GitLab automatically runs SAST scans during pipeline execution. Therefore GitLab recognizes python as the used programming language and launches corresponding static scans. Currently GitLab runs Bandit Python Security Scanner and Sempgrep to scan python code statically.

After the pipeline has been successfully completed, all findings can be viewed and evaluated on the security tab of the pipeline page. Vulnerabilities can either be dismissed or followed up and finally mitigated with the help of GitLab issues:

All vulnerabilities are listed at the merge request as well:

2) Secret Detection

Secret Detection highlights accidentally pushed secrets like passwords, API keys or tokens in the GitLab repositories. For this purpose GitLab uses Gitleaks for detection. For instance, if you have pushed AWS secrets to your development branch by mistake GitLab will notify you. In this manner you can mitigate that leaked secret early to prevent further distribution.

Enable Secret Detection for a specific GitLab project by creating the following .gitlab-ci.yml file:

1include:
2  - template: Security/Secret-Detection.gitlab-ci.yml

Looking at the security dashboard of the corresponding pipeline there are now vulnerabilities concerning pushed secrets

• aws-creds
• git-token
• fake-blog-key.pem

In addition to the leaked secrets, GitLab lists the secret type, severities and the path to the faulty source file.

3) Dependency Scanning

Dependency Scanning for python is done automatically by Gemnasium
and finds security vulnerabilities in your software dependencies.

Enable Dependency Scanning for a GitLab project by creating the following .gitlab-ci.yml file inside the root directory of the project:

1include:
2  - template: Security/Dependency-Scanning.gitlab-ci.yml

Selecting Dependency Scanning in the Tool drop down menu shows vulnerabilities affecting the dependencies of that project. Looking into the details of one finding there are a lot of information presented to help dealing with that vulnerability.

Sum up

In GitLab the integration of software security scanning at different stages of the software development lifecycle can be handled easily. Simply include the appropriate security templates and you are done. GitLab does the scanning automatically and reports its findings. Furthermore all security findings can be managed by GitLab Issues. In this way both version control and security scanning is hosted by one system: GitLab.

Of course you can run multiple security scans in one pipeline:

As soon as you merge your changes into the default branch both the Security Dashboard and the Vulnerability Report of the GitLab project display all findings:

Resources:

1. https://semgrep.dev/docs/cheat-sheets/python-command-injection/
2. https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools