Continuous vulnerability scanning

Continuous vulnerability scanning (CVS) is the capability that lets GitLab create vulnerability records without requiring a new CI/CD pipeline to run. When a new security advisory is published or updated, GitLab compares the advisory against the components already recorded for your projects and creates vulnerability records for any matches.

CVS relies on a CycloneDX SBOM report stored on the default branch to know which components your project uses. To produce this SBOM, a dependency scanning job must run at least once on the default branch. From then on, CVS detects newly published advisories against those components automatically, with no further pipeline runs required. When your application dependencies change, a new pipeline must run on the default branch to refresh the SBOM so CVS can evaluate the updated set of components. In most projects this happens as part of the regular workflow, because changing dependencies typically involves a code change that already triggers a pipeline.

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.

Merge request security reports

The security widget of a merge request compares the security report artifacts of the merge request’s pipeline against the security report artifacts of the latest pipeline on the target branch. Because CVS does not generate security report artifacts, the vulnerabilities CVS creates on the default branch are not part of that comparison.

As a result, when a pipeline in a merge request detects a vulnerability that CVS has already created on the default branch, the merge request reports that vulnerability as newly detected, even when the affected component is unchanged. After the next pipeline runs on the default branch, the security report artifacts of the target branch include the vulnerability, and later merge requests no longer report it as newly detected.

The limitation affects the merge request comparison only. On the default branch, the vulnerability report shows the vulnerability from the moment CVS creates it.

Malicious packages

CVS also compares your components against GitLab malware advisories, a private database of packages known to be malicious. When a component matches one of these advisories, GitLab creates a vulnerability in the same way it does for a security advisory.

Vulnerabilities created from a malware advisory always have Critical severity. Malware advisories state the severity directly rather than deriving it from a CVSS score.

Detection of malicious packages differs from the rest of CVS in three ways:

• GitLab evaluates only components on the default branch.
• GitLab supports fewer PURL types for malware advisories than for regular advisories. For the full list, see Supported package types.
• GitLab evaluates only advisories published in the previous 14 days when it synchronizes them. A pipeline matches older malware advisories the next time it runs dependency scanning on the default branch.

If an advisory is later withdrawn, GitLab stops matching against it and no new vulnerabilities are created from it. Vulnerabilities created before the advisory was withdrawn remain in the vulnerability report.

Detection of malicious packages uses the same project settings as continuous dependency scanning. Turning off continuous dependency scanning for a project also turns off detection of malicious packages.

Supported features

Continuous vulnerability scanning is available for the following security scans:

• Continuous dependency scanning for application dependencies.
• Continuous container scanning for container image packages.