Securing Your Code

Now that you know how to configure your GitLab CI/CD pipeline to verify that your project’s code is meeting its requirements, the next step in constructing a pipeline is to add jobs that look for security vulnerabilities. This is an optional step, but since GitLab makes it easy to add security scanning to your pipelines, and since there’s virtually no downside other than adding a few minutes to your pipeline’s runtime, we recommend that you enable all security scanners that are relevant to your projects.

We’ll start this chapter by providing an overview of GitLab’s general strategy around using security scanners; several aspects of security scanning are helpful to understand before you start learning about individual scanners. Then, we’ll explain the purpose of each of the seven types of security testing that GitLab offers: Static Application Security Testing (SAST), Secret Detection, Dynamic Application Security Testing...

Technical requirements

As with the previous chapters, you’ll get the most out of this chapter if you have an account on a GitLab instance (either self-managed or Software-as-a-Service (SaaS)) that you can log in to and use for practicing and experimenting with the concepts discussed.

Understanding GitLab’s security scanning strategy

There are a few fundamental principles underlying GitLab’s security scanners that will be useful for you to know before you learn about what each scanner does. Let’s look at those now.

GitLab uses open-source scanners

It might surprise you to learn that all the security scanners discussed in this chapter are third-party, open-source tools; none of them are developed in-house by GitLab. For example, IaC scanning is performed by the open-source tool Keeping Infrastructure as Code Secure (KICS), and Dependency Scanning is handled by the open-source tool Gemnasium.

That doesn’t mean that these third-party scanners are inferior to GitLab-developed software in any way. They are all rigorously researched and vetted by GitLab before they are adopted as official GitLab scanners. Furthermore, GitLab frequently reviews new open-source security scanners to see whether they should replace or supplement any of...

Using SAST to scan your source code for vulnerabilities

Let’s start our survey of scanners with SAST. We encourage you to read this section carefully, even if you don’t intend to use SAST, because many of the principles and practices involved with using SAST carry over to the other scanners as well. Understanding how to use SAST gives you a huge head start in terms of enabling, configuring, and reading the findings of other scanners.

Understanding SAST

SAST looks at your project’s source code, as opposed to interacting with your code as it runs. Sometimes, this approach is referred to as white-box scanning, meaning that the scanner looks inside your app to inspect its code instead of staying outside the app and simply analyzing its behavior.

This scanner looks for bad coding practices, anti-patterns, or the hallmarks of poorly designed or structured code, which are sometimes referred to as code smells, that could potentially result in exploitable security...

Using Secret Detection to find private information in your repository

You can think of Secret Detection as a special, focused version of SAST that’s dedicated to finding secrets that are accidentally lurking in your source code, such as United States social security numbers or AWS deploy keys. It operates in the same way as SAST – that is, by scanning your source code rather than by interacting with your executing application.

Secret Detection used to be part of GitLab’s SAST feature but was eventually spun off to become its own first-class security scanner. We are mentioning this so that you won’t be confused if you run into references in old documentation or blog posts suggesting that Secret Detection is performed by GitLab’s SAST scanner.

Understanding Secret Detection

Secret Detection looks for a wide variety of strings that represent secrets that should not normally be stored in files in a Git repository. In addition to the social security...

Using DAST to find vulnerabilities in web applications

Let’s move on to the next type of security scanner: DAST. This scanner interacts with your code as it runs instead of looking at your source code. If SAST and Secret Detection are examples of “white-box” testing – they look inside your app to see how it works – then DAST is a form of “black-box” testing – it just sends input and looks for potential problems or security vulnerabilities in the output, without knowing how your application performs that transformation of input into output.

Understanding DAST

DAST tests either web application URLs or Web API endpoints. If you feed DAST the URL of a website’s home page, it will visit that page, identify any links or clickable GUI elements on the page, follow those links or click those elements, and repeat the process. It will continue this “spidering” procedure until it has visited every page that it can...

Using Dependency Scanning to find vulnerabilities in dependencies

Why write your own functions when someone else has already written, tested, and documented a library to perform exactly what you need? It’s often easy to find third-party Python modules, Ruby gems, Java JARs, or other open-source software packages that speed up the development of your project. Unfortunately, these third-party dependencies can contain security vulnerabilities, and if you include them in your project, you inherit those problems. This is where GitLab’s Dependency Scanning feature steps in – it ensures that any dependencies you use are free of known vulnerabilities.

Understanding Dependency Scanning

Like SAST, Dependency Scanning supports many languages – including all of the major languages you’d expect – but not every language under the Sun. You can consult the GitLab documentation to see an up-to-date list of supported languages.

Dependency Scanning knows...

Using Container Scanning to find vulnerabilities in Docker images

Container Scanning does for Docker images what Dependency Scanning does for your project’s dependencies: it checks for known vulnerabilities in the particular versions of Linux distributions that your project uses as a base when it builds Docker images.

Understanding Container Scanning

If you package and deploy your application as a Docker image – or, technically, an Open Container Initiative-compliant image – you should use GitLab’s Container Scanning feature to find known vulnerabilities in the base Linux distribution that your image is built on top of.

If you haven’t worked with Docker images before, this might sound mysterious, but it’s not complicated. Think of a Docker image as a little bit like a virtual machine. There’s a special file called Dockerfile that serves as a “recipe” for creating that virtual machine. This Dockerfile file specifies...

Using License Compliance to manage licenses of dependencies

It can be easy to lose track of what software licenses are used by your project’s various dependencies. It’s also easy to forget which licenses are compatible with your project’s overall license, and which licenses should be excluded for various reasons. This is where GitLab’s License Compliance feature can help out.

Understanding License Compliance

Most open-source libraries are released under a software license. There are hundreds of licenses available – though only 20 or so are commonly used – and the legal details of each vary considerably. If you use a third-party library in your project, you must make sure that the library’s license and the license under which you intend to release your software are compatible with each other. If they are incompatible, you must replace that dependency with an alternative library that uses a friendlier license.

What do we mean...

Using IaC Scanning to find problems in infrastructure configuration files

In the last decade or so, the phrase “treat hardware as cattle, not pets” has been used to describe a new approach to managing computers. By thinking of hardware as a fungible commodity rather than a collection of special snowflakes, development and operations teams are liberated from carefully configuring and maintaining the computers they use to host deployment environments, run databases, serve web applications, or do any of the countless other tasks involved with developing and deploying software. By using so-called IaC tools such as Ansible or Terraform to configure and maintain the configuration state on hardware (whether real or virtual, local or cloud-based), system administrators can adjust server capacity, create new environments, or experiment with hardware configurations without worrying about how difficult it will be to revert their systems if something goes wrong or an experiment fails...

Understanding the different types of security reports

All GitLab security scanners display their results in three separate reports. Because each report shows results from all of the scanners, there’s no need to bounce around the GitLab GUI, collecting information from all the different scanners. However, each of the three report locations presents a slightly different spin on the scanners’ findings. It’s important to understand how these three reports differ, so let’s look at each one:

• The vulnerability report is the report that we’ve shown in screenshots throughout this chapter. It shows the findings of any scanner that ran during the last pipeline on your project’s default branch (normally main or master). If you want to know how secure your stable code base is, look at the vulnerability report. It won’t tell you anything about the state of security on any feature or bugfix branches – only the default branch.
• The...

Managing security vulnerabilities

Whenever any scanner except License Compliance finds a vulnerability, it grants that vulnerability the Needs Triage status. This status shows up in the vulnerability’s entry in the vulnerability report and the pipeline details page report.

You should decide what you intend to do about each vulnerability that has that status and change its status accordingly. Here are the possible status values:

• Dismissed means that you do not intend to remediate this vulnerability. Maybe you’ve determined that it’s a false positive, maybe you’ve decided it’s a real problem but isn’t worth fixing, or maybe you’ve realized that it doesn’t apply to your product or your users.
• Confirmed means that it’s a real problem, and you do intend to fix it. After setting a finding to this status, you would normally create an issue to track your progress as your team works to remediate this vulnerability...

Integrating outside security scanners

Many teams are committed to using one or more security scanners that are not part of GitLab’s security offering. Never fear – it’s usually possible to integrate outside scanners into your GitLab CI/CD pipelines.

Integration has two parts. First, you need to tell your pipeline to trigger the outside scanner. This is easy, so long as your scanner comes packaged in a Docker image and can be run from the command line:

1. Create a new pipeline job in the test stage (unless there’s a reason to run it elsewhere).
2. Use the images keyword in the job definition to specify the location of the Docker image that contains the scanner you’d like to add to your pipeline.
3. In the script section of the job definition, trigger the scanner using whatever CLI command you use when you run it manually. You might need to pass some options to the CLI command to control where it generates its results file, and what format...

Summary

Security is one of the biggest and most complicated topics covered in this book, so congratulations on making it through! Let’s take stock of what we learned in this chapter.

First, we covered some common principles that underly all of GitLab’s security scanners. We discussed the fact that all of the scanners are open-source tools developed outside of GitLab, and why that’s a good thing. We saw that some scanners use different analyzers to support different computer languages, though all scanners support the most commonly used languages, and some scanners are completely language-agnostic. We learned about the implications of packaging the scanners as Docker images. We saw that scanners don’t stop CI/CD pipelines when they find vulnerabilities, and we learned that it’s usually possible to integrate outside scanners into your pipelines if the GitLab-provided scanners aren’t sufficient for your needs.

Then, we marched through the...