Continuous Vulnerability Scanning
- Tier: Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
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.
New vulnerabilities may arise when Continuous Vulnerability Scanning triggers scans on all projects that contain components with supported package types.
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
- A project with dependencies supported by Continuous Vulnerability Scanning. See how to generate a CycloneDX SBOM report.
- Security advisories synchronized to the GitLab instance.
Supported package types
Continuous Vulnerability Scanning supports components with the following PURL types:
composer
conan
deb
gem
golang
maven
npm
nuget
pypi
rpm
apk
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.
RPM versions containing ^
are not supported. Work to support these versions is tracked in issue 459969.
APK versions containing leading zeros are not supported. Work to support these versions is tracked in issue 471509.
RPM packages in Red Hat distributions are not supported. Work to support this use case is tracked in epic 12980.
How to generate a CycloneDX SBOM report
Use a CycloneDX SBOM report to register your project components with GitLab.
GitLab offers security analyzers that can generate a report compatible with GitLab:
- Container Scanning
- Container Scanning For Registry
- Dependency Scanning
- Dependency Scanning CI/CD Component (experimental)
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.
Vulnerabilities are created according to the following scenarios:
After a security advisory is added or updated, it may take a few hours for the corresponding vulnerabilities to be added to your projects, provided the code base remains unchanged. Only advisories published within the last 14 days are considered for Continuous Vulnerability Scanning.
For existing security advisories, a vulnerability is only created if a new component is detected and either of the following conditions are true:
- The component is listed in a CycloneDX SBOM generated by Dependency Scanning.
- The feature flag
cvs_for_container_scanning
is enabled, and the component is listed in a CycloneDX SBOM generated by Container Scanning.
When vulnerabilities are no longer detected
Continuous Vulnerability Scanning automatically creates vulnerabilities when a new advisory is published
but it is not able to tell when a vulnerability is no longer present in the project. To do so, GitLab
still requires to have a Container Scanning or a
Dependency Scanning scan executed in a pipeline for the default branch,
and a corresponding security report artifact generated with the up to date information. When these reports
are processed, and when they no longer contain some vulnerabilities, these are flagged as such even if
they were created by Continuous Vulnerability Scanning. This behavior has been introduced in 17.1 with
issue 441490 and applies to scanners maintained
by GitLab (Trivy
, gemnasium
, gemnasium-python
, gemnasium-maven
).
Improvements to this behavior, including requiring only to have a updated SBOM uploaded, are planned in epic 8026.
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.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support