version v7.2.
For up-to-date documentation, see the
latest version.
How to Enable GitLab Container Scanning
2 minute read
.
Configure your pipeline
Add the following to your .gitlab-ci.yml and push to your repository:
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
By default, Container Scanning scans $CI_REGISTRY_IMAGE (the project’s container registry image).
(Optional) To scan a different image, use the CS_IMAGE variable:
container_scanning:
variables:
CS_IMAGE: example.com/user/image:tag
(Optional) To also report language-level vulnerabilities (in addition to OS packages):
container_scanning:
variables:
CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"
When both Container Scanning and Dependency Scanning are enabled, enabling language vulnerability scanning may produce duplicate findings.
Inventory your image dependencies
Dependency list
Container Scanning populates the same dependency inventory as Dependency Scanning. Go to Secure > Dependency list to browse packages by name, version, and license, and check whether any known vulnerabilities affect them.
See GitLab Dependency list documentation for details.
SBOM
Container Scanning automatically produces a CycloneDX SBOM for the scanned image. No additional configuration is required.
The SBOM is available as a pipeline artifact.
To download it, go to
Build > Artifacts
and select the container_scanning job to
find the file gl-sbom-report.cdx.json.
For the role of the SBOM in supply chain compliance (CRA, NTIA), see SBOM practice .
Analyze vulnerabilities
Container Scanning results appear in the same places and support the same triage workflows as Dependency Scanning — see Analyze vulnerabilities .