Carbonetes Scan on GitLab CI/CD

Created OnJanuary 8, 2024

Last Updated OnMarch 4, 2024

byMike Hogan

GitLab CI/CD is a tool built inside GitLab for continuous methodologies such as Continuous Integration and Continuous Deployment/Delivery. You can create a CI/CD pipeline on your GitLab repository by adding a .gitlab-ci.yml file on the root of your repository. This file will generate a pipeline that is triggered with every change on your repository. You can read this documentation [1] for more information about GitLab CI/CD.

Talking about GitLab CI/CD, Carbonetes was able to produce a fully managed security service that you can easily use right into your GitLab CI/CD pipeline. Carbonetes Scan can be placed between the build and push stage of your pipeline. Upon running your pipeline, Carbonetes Scan enables a complete vulnerability check. The results of that vulnerability check and the policy evaluation are placed right inside the Carbonetes Scan making it more efficient to detect and resolve issues without ever leaving GitLab CI/CD.

The Most Comprehensive Security Analysis in the Market

Carbonetes Scan can provide all the results of analysis faster than our competition. It uses a larger number of pods [6] to analyze your images rather than using the old-fashioned constant way of scanning them. Other than providing results faster, Carbonetes Scan also provides best-in-class results of container security analysis. It also runs the analysis smoothly and continuously [7].

The Benefits of having Carbonetes Scan in your GitLab CI/CD Pipelines

Carbonetes Scan is built into your GitLab CI/CD pipelines. Don’t waste a lot of time building your code through various security tools to check individual aspects of it. Carbonetes Scan can put together all container analysis into a single workflow that integrates with your current development workflow. Carbonetes Scan can trigger a comprehensive container security analysis seamless and automatic. Upon building your images, it runs the analysis on your codes for security risks, checks the results against the policy, and builds or stops the build based on that policy evaluation [8].

Getting Started with Carbonetes Scan

Prerequisites

To execute Carbonetes Scan right into your GitLab CI/CD pipeline, it requires valid Carbonetes credentials (email and password). You will also need an account on GitLab and create a repository before you can create a GitLab CI/CD pipeline.

If you don’t have any credentials yet, you can register now.

The table below shows the required credentials and their description:

CREDENTIALS	DESCRIPTION
CARBONETES_USERNAME *	The account username or email you use on Carbonetes.
CARBONETES_PASSWORD *	The account password on Carbonetes.
REGISTRY_URI *	The registry uri is managed in Carbonetes.
REPO_IMAGE_TAG *	The image to be scan under your registry.

How to use Carbonetes Scan on GitLab CI/CD

GitLab has a feature they called GitLab CI/CD environment variables. This feature is used to hide or mask any confidential information you may include in your .gitlab-ci.yml file. Follow the procedures below on how to configure your GitLab CI/CD pipeline.

how to configure your GitLab CI/CD pipeline

Head out to CI/CD Settings, look for the Variables section, and click the `Expand` button.

Variables section

Add all the required credentials as protected variables [3].

Configure .gitlab-ci.yml file to pull Carbonetes Scan into your pipeline. You can visit Dockerhub [4] to see all the available tags you can use on pulling Carbonetes Scan, but `carbonetes/carbonetes-scan:1.0.0` is the recommended tag for GitLab CI/CD. You can also check our public repository on GitLab [5] for an example GitLab CI/CD configuration.

.gitlab-ci.yml

Save all the changes on your repository to trigger the pipelines and proceed to the GitLab logs interface to see the results of the vulnerability check.

GitLab logs interface

Writing Configuration for GitLab CI/CD

Complete example of GitLab CI/CD configuration

Below is a full example of the .gitlab-ci.yml file configuration, you can use it as your reference.

variables:
CARBONETES_PASSWORD: ${CARBONETES_PASSWORD:?'CARBONETES_PASSWORD environment variable is missing'}
CARBONETES_USERNAME: ${CARBONETES_USERNAME:?'CARBONETES_USERNAME environment variable is missing.'}
REGISTRY_URI: ${REGISTRY_URI:?'REGISTRY_URI environment variable is missing.'}
IMAGE_NAME: ${REPO_IMAGE_TAG:?'REPO_IMAGE_TAG environment variable is missing.'}

stages:
- build
- scan
- publish

container_build:
stage: build
image: docker:stable
services:
- docker:stable-dind

script:
- docker build -t "$IMAGE_NAME" .

carbonetes-comprehensive-scan:
image: docker:stable
stage: scan
services:
- docker:stable-dind
before_script:
# Recommended image tag for GitLab
- docker pull carbonetes/carbonetes-scan:1.0.0
script:
# Execution of Carbonetes Scan
# Note: to be aligned in your CI/CD pipeline,
# make sure that you supply the same REPO_IMAGE_TAG
# that has been built within your pipeline stages.
- |
docker container run \
--env=REGISTRY_URI="$REGISTRY_URI" \
--env=REPO_IMAGE_TAG="$IMAGE_NAME" \
--env=CARBONETES_USERNAME="$CARBONETES_USERNAME" \
--env=CARBONETES_PASSWORD="$CARBONETES_PASSWORD" \
carbonetes/carbonetes-scan:1.0.0

container_publish:
stage: publish
image: docker:stable
services:
- docker:stable-dind

script:
- docker tag "$IMAGE_NAME" "${CI_REGISTRY_IMAGE}:latest"
- docker push “${CI_REGISTRY_IMAGE}:latest”

Getting the Outcome

Results provided by Carbonetes Scan

The table below shows the different results after Carbonetes Scan finished checking all the known vulnerabilities of a scanned image.

Result	Description
Vulnerabilities	A list of known security risks that can be exploited by a threat actor, listed with severities.
Software Compositions	Software that might cause a security risk listed with severities.
Software Dependencies	Pieces of software that rely on each other, listed with vulnerability counts.
Licenses	Legal compliances that are found on each software of the scanned image.
Malware	Virus threats that were found on the scanned image.
Secrets	Secret data found on each software of the scanned image.
Bill of Materials	A list of all the components that exist in software.
Policy Result	The result of the policy evaluation `PASSED` or `FAILED`.
Final Action	Decide if the build will `STOP` or `GO` based on the policy result.