Docker Security Scanning in GitLab

Last Updated on March 4, 2024

Over the last few years, GitLab has evolved and has become a fully-fledged DevOps platform. Thanks to many tools supporting continuous integration and software development, it became a model to follow. CI/CD with runners is a compelling set of tools that will allow us to build our project based on, for example, Docker and check it for security.

Are you switching to a DevOps operation model? Remember to secure your code with the first professional GitLab backup.

GitLab CI/CD

This name hides a toolkit that creates a modern and ideologically oriented DevOps workflow. Thanks to a well-configured pipeline, we can build, test, and review even the slightest change in the code and automate security checks of our application. The below picture shows the appearance of the pipeline prepared for an example project called Xopero, which will be built based on the Docker image. It’s worth mentioning that the essential thing in every project is to ensure a good backup, which Xopero provides us with. We can always add a manual stage to our pipeline, in which a team member will have to perform a backup periodically.

Docker scanning with Runners 

Runners is a set of tools that allow you to use any platform to build your application. The possibilities of the Runner do not end there because the most important thing is not that it can be installed and run on Linux, Windows, or Windows (the complete list is available here), but the fact that the Runner can use different executors. The following is the code needed to register the Runner on the Windows operating system. We can note that we will be using Docker, which should have already been installed in the system. We need to run that command via PowerShell with Administrator privileges.

.\GitLab-runner.exe register `
  --url https://gitlab.com/ `
  --registration-token GR1348941 `
  --name Xopero_Docker `
  --tag-list xopero,docker `
  --executor docker `
  --docker-image alpine:latest `
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock `
  --docker-volumes /cache `
  -n

A Runner prepared in this way will be visible on the portal in the tab settings -> CI/CD -> Runners. A registered and active Runner (green dot shown in the figure below) will make the configured pipeline trigger build and deployment executor by that Runner.

Testing with SAST

Static Application Security Testing is part of the test suite that we can enable and use for our project. SAST will perform an analysis of our project for known vulnerabilities. We can enable and configure SAST in the .gitlab-ci.yml file by adding the following code:

sast:
 stage: test
include:
 - template: Security/SAST.gitlab-ci.yml

This will allow us to run SAST for our project, tests which we can, of course, edit and, if necessary, expand with our own and custom tests. It’s worth noting that new test tasks are added to our pipeline.

Of course, SAST tools are not the only way to scan our project for security. I encourage you to check the official documentation available on GitLab, as well as read the available tools in Security & Compliance -> Configuration. In addition to changes to the pipeline itself, GitLab SAST will prepare automatically generated results based on the tests performed.

Summarizing

A modern approach to workflow, which brings DevOps along with continuous integration (CI) and continuous delivery (CD), well configured, will allow us to accelerate and automate the work of our team. However, the security of our applications and codes must not be forgotten. For this reason, our pipeline should always include tests that will check the code itself and the entire implementation with the used executor.