Validating Images with Gitlab CI / CD

Hello everyone, on the eve of the start of the course “CI / CD on AWS, Azure and Gitlab” prepared a translation of interesting material.

In this article, we will talk about how to check container images on the Gitlab CI / CD platform using Sysdig secure.

Container images that do not comply with the security policies defined in Sysdig Secure will not be published to the container registry and will stop the pipeline.

Vulnerability Finder with Gitlab CI / CD

Gitlab CI / CD is open source continuous integration and delivery serverbuilt into the Gitlab software development and collaboration platform.

After you configure Gitlab CI / CD for your repository, each time developers commit to the repository’s tracked branches, pipeline scripts will run automatically.

Such pipelines can be used to automate many processes. For example, for QA testing, creation of software distribution artifacts (such as Docker images or Linux packages) or, for what we will talk about in this article – to verify the configuration, search for vulnerabilities and verify compliance.

Checking Images on the Gitlab CI / CD Pipeline: shift left security

As elsewhere in IT, the sooner you find a vulnerability in a container, the faster and easier you can fix it without consequences.

Implementation vulnerability checks into your pipeline assembly is a good practice for several reasons:

  • Existing vulnerabilities will never go to production;
  • You can immediately use the “secure-by-default” approach, knowing that any image in your container registry has already passed all security checks, and you do not need to perform a manual check after the fact.
  • The author of the image will immediately receive a notification, without departing from the development context. So the problem will be fixed faster and easier than when someone else detects it after a few months.

Sysdig Secure offers a full-featured set of tools for checking container images along with many other container security verification features such as time threat detection fulfillment with machine-based profiling and extensible threat detection patterns out of the box, forced use Kubernetes PSPsresponding to incidents and expertise on the conformity. Let’s take a look at how the Sysdig Secure Image Validation service works with Gitlab.

Security Check Requirements on Gitlab

To complete the following steps, you will need:

Configuring the Gitlab CI / CD Pipeline for Image Inspection with Sysdig Secure

We will see in practice how these two platforms can be integrated. With this guide, you will learn how to work with Sysdig Secure Image scanning in minutes.

Configure Access Credentials

The Gitlab CI / CD pipeline will need access credentials in order to communicate with the Sysdig Secure backend. In order to do everything right, copy the access token from Sysdig UI Settings> User profile.

Then set up a new global variable for your Gitlab project:

  1. In your project, take a look at Settings> CI / CD and select Variables.
  2. Create a new variable SYSDIG_SECURE_TOKEN and add the Sysdig Secure API key in the field value.
  3. Click on the button Maskedso that your API token is not printed in the pipeline logs.

Gitlab pipeline definition

First, we need a Docker file that defines the image that you will collect. You can upload any Docker file you want to your project, or simply use the following example:

FROM debian:stretch
RUN apt update && apt install python-pip python-numpy openssh-server -y && rm -rf /var/lib/apt
RUN pip install flask
EXPOSE 5000 22
ENTRYPOINT ["python", "./"]

Then you need to create a new file .gitlab-ci.yml at the root of the project. This file will describe all the necessary steps (stages) of the assembly of our environment. He will determine all the necessary stages.

There are 3 stages in our pipeline now:

  • Assembly of the container image;
  • Scanning an image for vulnerabilities or policy violations;
  • Moving the image to the destination repository.
  CI_REGISTRY_IMAGE: "sysdiglabs/dummy-vuln-app"
  SCAN_IMAGE_NAME: "sysdiglabs/secure_inline_scan:latest"

  image: docker:latest
  stage: build
    - docker:dind
    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
    - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"
    - docker push "$CI_REGISTRY_IMAGE"
    - master

Build a container image

The image is assembled using docker build --pull -t "$CI_REGISTRY_NAME". It takes instructions from your Docker file and generates a new local image, which will be checked in the next step.

Scanning for Vulnerabilities

The next stage is checking the containers. Here we will check the image for vulnerabilities and check the configuration, storing the results on the Sysdig backend.

One of the advantages of Sysdig local scanning is that you do not lose control over your images, since the image does not need to be moved to another registry or exposed from the outside in order to perform the scan. It happens inside the runner’s, and only results are sent to Sysdig Secure.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"

At this point, Sysdig Secure will return an error code if the image meets any of the stop conditions specified in your policy (for example, critical vulnerability). Stopping the pipeline will prevent the transfer of vulnerable images to the container registry.

In Sysdig Secure, we can look at additional information and understand why the security check failed to complete:

As you can see in the screenshot, the container leaves open port 22, which is in the list of forbidden ports, and also contains some serious vulnerabilities in the Python library.

Move image to destination repository

After a successful vulnerability check, the pipeline will docker push and the image will be published to the container registry. If you do not provide any credentials or remote storage, Gitlab uses default.


Via Sysdig secure image scanning you can check images in the Gitlab CI / CD pipeline without sending them from the infrastructure to the public or intermediate registry, check the configuration and prevent leakage of vulnerabilities for production.

Find known vulnerabilities and check the configuration for compliance with security recommendations, including Dockerfile instructions, white and black lists of packages or third-party libraries installed in the base image, such as JAR / WAR files in Java or language package managers such as npm for Javascript, pip for Python and gem for Ruby.

In the event of a failure, you can quickly report this to the container author to quickly solve the problem and create a secure-by-default container security policy. To try Sysdig Secure, you can request demo version today!

That’s all. Learn more about the course can be here.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *