Image scanning for Gitlab CI/CD

In this blog post we are going to cover how to perform container image scanning on the Gitlab CI/CD platform using Sysdig Secure.

Container images that don’t meet the security policies that you define within Sysdig Secure won’t be published to the container registry and will stop the pipeline.

Vulnerability scanning for Gitlab CI/CD

Gitlab CI/CD is an open source continuous integration and delivery server integrated with the Gitlab software development and collaboration platform.

Once you have configured Gitlab CI/CD for your repo, every time a developer pushes a commit to the tracked repository branches, the pipeline scripts will be automatically triggered.

You can use these pipelines to automate many processes. Common tasks include QA testing, building software distribution artifacts (like Docker images or Linux packages) or, as is the case for this article, validating configuration, vulnerabilities and compliance.

Image scanning on Gitlab CI/CD pipeline: shift left your security

Like most things in IT, the earlier you detect container security issues, the easier and faster they are to fix without any further consequences.

Embedding vulnerability scanning in your build pipeline is a best practice for several reasons:

• Existing vulnerabilities will never reach your production clusters.
• You can adopt a secure-by-default approach when you know any image available in your Container Registry has already passed all the security policies, as opposed to manually checking after-the-fact.
• The original author will be instantly notified, when still has all the domain context. The issue will be substantially easier and faster to fix this way than if found by any other person months later.

Sysdig Secure offers a full featured container image scanning functionality, among many other container security features like runtime threat detection with machine-learning-based profiling and extensive out-of-the-box detection patterns, enforcement using Kubernetes PSPs, incident response and forensics or compliance. Let’s see how we can make Sysdig Secure image scanning service work together with Gitlab.

Pre-requisites for security scanning on Gitlab

To reproduce the steps in this post you will need:

• A Gitlab account.
• A Sysdig Secure DevOps platform account.

Gitlab CI/CD pipeline setup for image scanning with Sysdig Secure

Following a practical example we are going to demonstrate how to integrate these two platforms. This will get you up and running with Sysdig Secure Image scanning in minutes.

Configuring access credentials

The Gitlab CI/CD pipeline will require access credentials to communicate with the Sysdig Secure backend, to achieve this copy the API access token from the Sysdig UI Settings > User profile.

Then, configure a new global variable for your Gitlab project:

1. In your Gitlab Project, view your project’s Settings > CI/CD and expand Variables.
2. Create a new variable named SYSDIG_SECURE_TOKEN, and paste your Sysdig Secure API key in the value field.
3. Toggle the Masked button to avoid printing your API token in the pipeline logs.

Gitlab pipeline definition

First, you will need a Dockerfile defining the image that you intend to build. You can upload any Dockerfile you want to your project, or just write a simple 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
COPY app.py /app.py
EXPOSE 5000 22
ENTRYPOINT ["python", "./app.py"]

Then, you need to create a new .gitlab-ci.yml file in your project root. This file serves as the master build file which contains all the necessary build steps (stages) our environment. This file allows you to create as many stages you need for your builds.

We have three stages in this pipeline:

1. Building the container image
2. Scanning the image for vulnerabilities or policy violations
3. Pushing the image to the final repository

Build stage

The building of the image happens with the docker build --pull -t "$CI_REGISTRY_NAME". It takes the instructions from your Dockerfile and generates a new local image that will be scanned in the next step.

Inline scanning stage

The next stage is the container scan stage. At this stage we will be scanning the image for vulnerabilities and validating configuration, storing the results on the Sysdig backend.

One of the benefits of Sysdig’s local scanning approach is that you don’t lose control over your images, as the image doesn’t need to be pushed to any registry or exposed externally in order to scan it, the scanning happens inside the runner and only the results are sent to Sysdig Secure.

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

Sysdig Secure will return an error code for this stage if the image contains any of the stop conditions configured in your policy (for example, a critical vulnerability). Stopping the pipeline will prevent pushing vulnerable images to the container image registry.

We can see further information in Sysdig Secure and check why the security scanning failed:

As we can see the image, it is exposing port 22 which is in the list of denied ports and it contains some high vulnerabilities in a Python library.

Publishing stage

After a successful vulnerability scan, the pipeline will execute docker push and the image will be published to the container registry. If you don’t specify any credentials or remote repository, Gitlab will use the default one.

Conclusions

Using Sysdig Secure image scanning you can scan your container images within your Gitlab CI/CD pipeline without sending them out of your infrastructure to a public or staging registry, validating configuration and preventing vulnerabilities from reaching your production environment.

Find known vulnerabilities and validate configuration against security best practices, including Dockerfile instructions, whitelist or blacklist specific packages or 3rd party libraries installed on top of the base image like Java JAR/WAR files, or language specific package managers like Javascript’s npm, Python’s pip or Ruby’s gem.

Fail fast, inform the container author right away to address it quickly and create a secure-by-default container security policy. To try Sysdig Secure yourself, request a demo today!