How to Integrate Docker Scout with GitLab

GitLab is a DevOps platform that combines the functionality of a Git repository management system with continuous integration (CI) and continuous delivery (CD). It is a self-hosted platform that can be used to manage the entire software development lifecycle, from planning and code development to testing, deployment, and monitoring.

GitLab is based on the Git version control system, but it adds a number of features that make it ideal for DevOps teams. These features include:

• Code review: GitLab provides a built-in code review system that makes it easy for team members to collaborate on code changes.
• Issue tracking: GitLab allows you to track bugs and other issues related to your code.
• CI/CD: GitLab provides a built-in CI/CD pipeline that can be used to automate the building, testing, and deployment of your software.
• Security: GitLab provides a number of security features, such as vulnerability scanning and code signing.
• Compliance: GitLab provides a number of compliance features, such as audit logging and role-based access control.

GitLab is a popular choice for DevOps teams of all sizes, from small startups to large enterprises. It is a powerful platform that can help you to improve the quality and speed of your software development process.

Here are some of the benefits of using GitLab:

• Improved collaboration: GitLab makes it easy for team members to collaborate on code changes and track the progress of projects.
• Increased productivity: GitLab's built-in CI/CD pipeline can help you to automate the building, testing, and deployment of your software, which can save you a lot of time and effort.
• Improved security: GitLab's security features can help you to identify and fix vulnerabilities in your code before they are exploited.
• Increased compliance: GitLab's compliance features can help you to meet the requirements of various industry regulations.

If you are looking for a DevOps platform that can help you to improve your software development process, GitLab is a great option to consider.

What is Docker Scout?

Docker Scout is intended for anyone involved in the SDLC that focuses on maintaining or improving the security of their application. This includes developers, DevOps engineers, security professionals, and anyone else involved in the software development lifecycle. The feature is particularly useful for organizations that need to ensure the security and compliance of their container images and want to have a detailed understanding of the software supply chain. Docker Scout can be used by individuals or teams, and is available to users with a paid Docker subscription.

Docker Scout provides developers and organizations with detailed insights into the security of their container images, enabling them to make informed decisions about how to address vulnerabilities and improve the overall security of their software.

How is Docker Scout different from other security tools?

Scout ditches traditional scheduled scans for a modern event-driven model. If a new vulnerability affecting your images is announced, Scout shows your updated risk within seconds. It’s always alert, updating vulnerability info from 17+ sources in real time. This data is compared with your Software Bill of Materials for up-to-the-minute accuracy.

You can also add your internal advisories to the mix, ensuring a comprehensive view of your security. So, with Scout, you’ll always be a step ahead, swiftly spotting and fixing vulnerabilities without the wait.

Docker Scout is designed with developers in mind and integrated into Docker. With Docker Scout, spend less time searching for and fixing vulnerabilities, and more time developing your code. Docker is building Docker Scout to sit as a layer on top of the Docker ecosystem to help developers build and maintain a secure software supply chain. Right now, Docker is focussed on helping with vulnerability remediation.CVE-to-package matching (using PURLs to help avoid false positives) and our SBOM-to-CVEdb matching (no need to rescan) are both nice improvements to the current Developer experience.

While there are similarities and differences between all tools of this nature, Docker Scout stands out by offering both visibility into the dependencies called in specific layers of the images, and remediation options directly in existing developer workflows.

Demo: Scout Integration with GitLab for Voting App

Click here to see the Source Code

Getting Started

The example describes a GitLab CI pipeline setup that builds a Docker image and performs vulnerability scanning using Docker Scout. The behavior of the pipeline depends on whether the commit is made to the default branch or a different branch. Here's a breakdown of how this setup works:

This section shows how Docker Scout can be integrated with the GitLab CI platform. The following voting-app demo example runs in GitLab CI in a repository containing a Docker image’s definition and contents. Triggered by a commit, the pipeline builds the image. If the commit was to the default branch, it uses Docker Scout to get a CVE report. If the commit was to a different branch, it uses Docker Scout to compare the new version to the current published version.

Follow the steps:

1. Login to Gitlab and click on “New project”

2. Import the existing GitHub repository

3. Choose GitHub

4. Search for Scout-Voting app and choose your GitHub Scout Voting Demo App.

5. Click on “Import”.

Replace .github/workflows with the following .gitlab-ci.yml file under the root directory of your GitLab project repository.

image: docker:latest

stages:
  - build

services:
  - docker:dind

before_script:
  - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY

  # Install curl and the Docker Scout CLI
  - >
    apk add --update curl &&
    curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s -- &&
    apk del curl &&
    rm -rf /var/cache/apk/*

  # Login to Docker Hub required for Docker Scout CLI
  - echo "$DOCKER_HUB_PAT" | docker login --username "$DOCKER_HUB_USER" --password-stdin


build_vote:
  stage: build
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE/vote:${CI_COMMIT_REF_SLUG}" ./vote
    - docker push "$CI_REGISTRY_IMAGE/vote:${CI_COMMIT_REF_SLUG}"
    - docker scout cves "$CI_REGISTRY_IMAGE/vote:${CI_COMMIT_REF_SLUG}" --exit-code --only-severity critical,high
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - vote/Dockerfile

build_worker:
  stage: build
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE/worker:${CI_COMMIT_REF_SLUG}" ./worker
    - docker push "$CI_REGISTRY_IMAGE/worker:${CI_COMMIT_REF_SLUG}"
    - docker scout cves "$CI_REGISTRY_IMAGE/worker:${CI_COMMIT_REF_SLUG}" --exit-code --only-severity critical,high
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - worker/Dockerfile  

build_result:
  stage: build
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE/result:${CI_COMMIT_REF_SLUG}" ./result
    - docker push "$CI_REGISTRY_IMAGE/result:${CI_COMMIT_REF_SLUG}"
    - docker scout cves "$CI_REGISTRY_IMAGE/result:${CI_COMMIT_REF_SLUG}" --exit-code --only-severity critical,high
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - result/Dockerfile    

• image: docker:latest: This specifies the base Docker image that will be used to run the CI/CD pipeline. In this case, it's using the docker:latest image, which means the pipeline will run within a Docker container. stages: This section defines the different stages of the CI/CD pipeline. Each job in the pipeline belongs to a specific stage.
• services: This section defines services that will be made available to the pipeline jobs. Here, the docker:dind service provides a Docker-in-Docker environment, allowing jobs to build and work with Docker containers.
• before_script: This section contains commands that will be executed before running any of the jobs in the pipeline. It's a good place to put common setup steps that are required for multiple jobs.
• image: docker:latest: This specifies the base Docker image that will be used to run the CI/CD pipeline. In this case, it's using the docker:latest image, which means the pipeline will run within a Docker container. stages: This section defines the different stages of the CI/CD - pipeline: Each job in the pipeline belongs to a specific stage.
• services: This section defines services that will be made available to the pipeline jobs. Here, the docker:dind service provides a Docker-in-Docker environment, allowing jobs to build and work with Docker containers.
• before_script: This section contains commands that will be executed before running any of the jobs in the pipeline. It's a good place to put common setup steps that are required for multiple jobs.

Overall, this GitLab CI/CD configuration defines a pipeline with three stages (build) and three jobs (build_vote, build_worker, build_result). Each job builds a Docker image for a specific service (vote, worker, result) and performs vulnerability scanning using the Docker Scout CLI. The jobs are triggered based on the presence of Dockerfile files in the respective service directories and when the pipeline is triggered from a branch.

6. Go to Settings > CI/CD > General Pipelines and add .gitlab-ci.yml as CI/CD configuration file:

Gitlab Project directory for Voting App

Here’s the layout of the project directory.

Note: I have skipped K8s specific files. Kubernetes-specific YAML files, like Kubernetes Deployment files, might trigger the use of buildpacks in your CI/CD pipeline. When Kubernetes-specific files are present, GitLab's CI/CD system could interpret this as an indication that you're deploying to Kubernetes, and therefore, it might use Cloud Native Buildpacks (CNB) to build your application image.

tree scout-demo-voting-app
scout-demo-voting-app
├── LICENSE
├── MAINTAINERS
├── README.md
├── architecture.excalidraw.png
├── docker-compose.images.yml
├── docker-compose.yml
├── gl-auto-build-variables.env
├── healthchecks
│   ├── postgres.sh
│   └── redis.sh
├── result
│   ├── Dockerfile
│   ├── docker-compose.test.yml
│   ├── package-lock.json
│   ├── package.json
│   ├── scout-fix-package.json
│   ├── server.js
│   ├── tests
│   │   ├── Dockerfile
│   │   ├── render.js
│   │   └── tests.sh
│   └── views
│       ├── angular.min.js
│       ├── app.js
│       ├── index.html
│       ├── socket.io.js
│       └── stylesheets
│           └── style.css
├── seed-data
│   ├── Dockerfile
│   ├── generate-votes.sh
│   └── make-data.py
├── vote
│   ├── Dockerfile
│   ├── app.py
│   ├── requirements.txt
│   ├── static
│   │   └── stylesheets
│   │       └── style.css
│   └── templates
│       └── index.html
└── worker
    ├── Dockerfile
    ├── Program.cs
    ├── Worker.csproj
    └── dockerfile.orig

12 directories, 35 files

1. Go to Pipelines on the left sidebar and initiate the pipeline.

You will see that the overall build process gets successfully executed.

1. Click on “build_result” and you will be able to see the positive results.

By integrating Docker Scout with GitLab, you can automatically scan your Docker images for vulnerabilities as part of your CI/CD pipeline. This helps you to catch and fix security issues early on, before they cause any damage.

References

• Docker Scout CLI
• Docker Scout Integration with GitHub Action
• Docker Scout Integration with CircleCI
• Docker Scout Integration with Azure DevOps Pipeline
• Docker Scout Integration with Jenkins