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
latestimages 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.