Continuous Vulnerability Scanning

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
History
  • Continuous dependency scanning introduced with feature flags dependency_scanning_on_advisory_ingestion and package_metadata_advisory_scans enabled by default.
  • Generally available in GitLab 16.10. Feature flags dependency_scanning_on_advisory_ingestion and package_metadata_advisory_scans removed.
  • Continuous container scanning introduced in GitLab 16.8 with a flag named container_scanning_continuous_vulnerability_scans. Disabled by default.
  • Continuous container scanning enabled on self-managed, and GitLab Dedicated in GitLab 16.10.
  • Generally available in GitLab 17.0. Feature flag container_scanning_continuous_vulnerability_scans removed.

Continuous Vulnerability Scanning looks for security vulnerabilities in your project’s dependencies by comparing their component names and versions against information in the latest security advisories.

When security advisories are added or updated, Continuous Vulnerability Scanning triggers a scan on all projects where components with supported package types exist. If an advisory affects a dependency, Continuous Vulnerability Scanning creates a vulnerability in the project.

Vulnerabilities created by Continuous Vulnerability Scanning use GitLab SBoM Vulnerability Scanner as the scanner name.

In contrast to CI-based security scans, Continuous Vulnerability Scanning is executed through background jobs (Sidekiq) rather than CI pipelines and no Security report artifacts are generated.

Prerequisites

note
If a new component is detected, and an advisory for it already exists, a vulnerability is not created. Support for this feature can be tracked in epic 8026.

Supported package types

Continuous Vulnerability Scanning supports components with the following PURL types:

  • composer
  • conan
  • deb
  • gem
  • golang
  • maven
  • npm
  • nuget
  • pypi

Work to support apk and rpm package URL types is tracked in issue 428703.

Go pseudo versions are not supported. A project dependency that references a Go pseudo version is never considered as affected because this might result in false negatives.

How to generate a CycloneDX SBOM report

GitLab offers security analyzers that can generate a CycloneDX SBOM report compatible with GitLab:

Checking new vulnerabilities

New vulnerabilities detected by Continuous Vulnerability Scanning are visible on the Vulnerability Report. However, they are not listed on the Dependency List or in the pipeline where the affected SBOM component was detected.

After a security advisory is published, it might take a few hours before the corresponding vulnerabilities are added to your projects.

Security advisories

Continuous Vulnerability Scanning uses the Package Metadata Database, a service managed by GitLab which aggregates license and security advisory data, and regularly publishes updates that are used by GitLab.com and self-managed instances.

On GitLab.com, the synchronization is managed by GitLab and is available to all projects.

On GitLab self-managed, you can choose package registry metadata to synchronize in the Admin Area for the GitLab instance.

Data sources

Current data sources for security advisories include:

Contributing to the vulnerability database

To find a vulnerability, you can search the GitLab Advisory Database. You can also submit new vulnerabilities.

Continuous Vulnerability Scanning For Container Registry

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
History
The availability of this feature is controlled by a feature flag. For more information, see the history.

Continuous Vulnerability Scanning For Container Registry identifies security vulnerabilities in Docker images stored in the GitLab Container Registry, specifically those tagged as latest.

When an image is pushed with the latest tag, a container scanning job is automatically triggered against the default branch of the project.

As security advisories are added or updated, this feature actively scans the Docker images in the Container Registry, identifies any affected images, and generates vulnerabilities in the project.

By default there is a limit of 50 scans per project per day.

Prerequisites

  • Ensure that the security configuration Container Scanning For Registry is enabled.
  • The project must contain a repository. Note that if you are utilizing an empty project solely for storing container images, this feature won’t function as intended. As a workaround, ensure the project has an initial commit on the default branch.