GitLab container scanning checks container images for known vulnerabilities, mainly in base images and operating system packages. Language packages, such as Python or npm libraries inside the image, are not reported by default. You enable them with a setting, and then dedupe against dependency scanning.
What it does
The GitLab documentation describes container scanning as part of software composition analysis. It uses the Trivy scanner. The image must already be built and pushed to a registry, because the job pulls it from there. Results appear in the pipeline Security tab and as a JSON report. With Trivy it also produces a CycloneDX SBOM.
What is covered by default
| Layer | Default behavior |
|---|---|
| OS packages (apt, yum, apk, tdnf) | Reported by default |
| Language packages | Not reported until you set CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN to "false" |
| Image sources | GitLab registry, external registries via CS_IMAGE, and Docker format archives |
| OCI tarballs | Not supported |
The supported distributions listed include Alpine, Debian, Ubuntu, RHEL, Rocky, Alma, Amazon Linux and Distroless. If you turn on language package scanning while dependency scanning is also on, expect duplicate findings.
Tier differences
Free and Premium include configuration, JSON reports, SBOM generation and end of life OS detection, with an advisory database limited to time-delayed community content. Ultimate adds report data in merge requests, the full GitLab advisory database, auto-remediation, allowlisting and container scanning for the registry.
Registry scanning
On Ultimate, registry scanning is enabled per project. When an image is pushed with the latest tag, a scan runs against the default branch. It produces an SBOM and relies on continuous vulnerability scanning, so findings appear when new advisories are published. The page notes a limit of 50 scans per project per day.
Caveats before you rely on it
- The Grype analyzer is no longer maintained and stops working in GitLab 19.0.
- Auto-remediation needs access to the Dockerfile.
- In FIPS mode, scanning images in authenticated registries is not supported.
- Offline use needs a local registry and a mirrored analyzer image.
- Test config changes in a merge request first, because mistakes can cause many false positives.
How to read a long result
A scan of a large base image can list hundreds of findings. Start with the ones that have a fix, then those in packages your app calls, then the rest. A newer base image often removes a large share at once.
Where a dedicated scanner fits
A separate scanner helps if your images live in several registries or you want container findings next to code and dependency findings. Safeguard offers SBOM and dependency scanning plus a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which layer each finding comes from, base image or application.
Quick check
Does container scanning replace dependency scanning?
No. The GitLab page recommends using it alongside dependency scanning.
Why do I see duplicate findings?
Enabling language package scanning in container scanning can duplicate findings that dependency scanning already reports.
Sources
Last reviewed: 19 October 2026.
