gitlab

A complete guide to GitLab Container Scanning (opens in new tab)

GitLab provides multiple container-scanning methods to detect vulnerabilities throughout the container lifecycle, from CI builds to registry monitoring. The guide emphasizes scanning early to identify risks in base images, operating-system packages, and application dependencies before they reach production. It covers pipeline-based scanning in detail and introduces registry scanning for continuously monitoring published images.

Why Container Scanning Matters

  • Container vulnerabilities can arise during image creation or while containers are running in production.
  • Base images, OS packages, and application dependencies may contain exploitable flaws.
  • Scanning supports a shift-left security strategy by detecting issues before deployment.
  • Container scanning is part of Software Composition Analysis (SCA), helping teams understand and secure external dependencies.

Pipeline-Based Container Scanning

Pipeline-based scanning analyzes container images during CI/CD execution.

  • Purpose: Detect vulnerabilities before deployment and help prevent unsafe images from reaching production.
  • Scanner: GitLab uses Trivy to identify known vulnerabilities.
  • Availability: Free, Premium, and Ultimate tiers, with additional features in Ultimate.
  • Automatic setup: Use Secure > Security configuration and configure Container Scanning through a generated merge request.
  • Manual setup: Include the following template in .gitlab-ci.yml:
include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

Common Configuration Options

  • Scan a specific image by overriding CS_IMAGE:
include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: myregistry.com/myapp:latest
  • Restrict findings to a severity threshold with CS_SEVERITY_THRESHOLD:
container_scanning:
  variables:
    CS_SEVERITY_THRESHOLD: "HIGH"

This example reports only High and Critical vulnerabilities.

Merge Request Integration

  • Findings appear in the merge request’s Security Scanning section.
  • Developers can review newly introduced and existing vulnerabilities during code review.
  • Each finding includes severity, affected packages, and remediation guidance.
  • This integrates container security into the development workflow instead of treating it as a separate post-deployment gate.

Vulnerability Report

The centralized Vulnerability Report is available under Security & Compliance > Vulnerability Report.

  • Aggregates container vulnerabilities across project branches.
  • Supports filtering by severity, status, scanner type, and container image.
  • Vulnerabilities can be assigned to team members and marked as detected, confirmed, resolved, or dismissed.
  • Teams can add comments and link related issues to track remediation.
  • Details show the affected images and layers, helping identify the source of a vulnerability.

Dependency List and SBOM

GitLab’s Dependency List provides a software bill of materials for container images.

  • Lists packages, libraries, and dependencies detected by Container Scanning.
  • Shows both base operating-system packages and application dependencies.
  • Supports filtering by package manager, license type, and vulnerability status.
  • Connects dependencies with their vulnerabilities for security and compliance analysis.

Container Scanning for the Registry

Registry scanning automatically analyzes images pushed to GitLab’s Container Registry with the latest tag.

  • Purpose: Continuously monitor registry images without requiring manual pipeline triggers.
  • Availability: Ultimate tier only.
  • Trigger: GitLab’s security policy bot scans latest images against the default branch.
  • Continuous monitoring: Works with Continuous Vulnerability Scanning to detect newly disclosed vulnerabilities.

Enabling Registry Scanning

  • Go to Secure > Security configuration.
  • Find Container Scanning for Registry.
  • Toggle the feature on.

Prerequisites

  • The user must have the Maintainer role or higher.
  • The project must contain at least one commit on its default branch.
  • Container Registry notifications must be configured.
  • The Package Metadata Database must be configured; it is enabled by default on GitLab.com.

GitLab’s scanning options support both preventive CI/CD checks and ongoing registry monitoring. Teams should use pipeline-based scanning to catch vulnerabilities before deployment and registry scanning when they need continuous visibility into published images.