View vulnerabilities in a pipeline

Introduced in GitLab 12.3.

To view vulnerabilities in a pipeline:

On the top bar, select Menu > Projects and find your project.
On the left sidebar, select CI/CD > Pipelines.
From the list, select the pipeline you want to check for vulnerabilities.
Select the Security tab.

A pipeline consists of multiple jobs, which may include security scans. When a job declares and produces security scan reports using artifacts:reports, GitLab parses and ingests the contents of these reports to create vulnerabilities associated with the project the pipeline belongs to.

If a job fails to finish, the pipeline vulnerability report doesn't show vulnerability findings detected by this job. For example, if a pipeline contains DAST and SAST jobs, but the DAST job fails by returning a non-zero exit code, the report doesn't show DAST results.

The pipeline vulnerability report only shows results contained in the security report artifacts. This report differs from the Vulnerability Report, which contains cumulative results of all successful jobs, and from the merge request security widget, which combines the branch results with cumulative results.

Before GitLab displays results, the vulnerability findings in all pipeline reports are deduplicated.

Scan details

Scan details shows a summary of vulnerability findings in the pipeline and the source reports.

GitLab displays one row of information for each scan type artifact present in the pipeline.

Note that each scan type's total number of vulnerabilities includes dismissed findings. If the number of findings in the report doesn't match the number in Scan details, ensure that Hide dismissed is disabled.

Download security scan outputs

Introduced in GitLab 13.10.

Improved in GitLab 14.2.

Depending on the type of security scanner, you can download:

A JSON artifact that contains the security scanner report.
A CSV file that contains URLs and endpoints scanned by the security scanner.

To download a security scan output:

In Scan details, select Download results:
- To download a JSON file, select the JSON artifact.
- To download a CSV file, select Download scanned resources.

Scan results

This shows a list of the combined results for all security report artifacts. The filters work like the Vulnerability Report filters, but they are limited to Severity and Tool, with the addition of a Hide dismissed toggle.

When you review the vulnerability findings reported in the pipeline, you can select one or more entries for dismissal, similar to Dismissing a vulnerability in the Vulnerability Report.

When you merge the branch corresponding to the pipeline into the default branch, all reported findings are combined into the Vulnerability Report. Scan results in pipelines executed on the default branch are incorporated once the pipeline finishes.

Existing vulnerability status	Dismissed in pipeline?	New vulnerability status
any	Yes	Dismissed
Dismissed	any	Dismissed
Confirmed	No	Confirmed
Needs triage (Detected)	No	Needs triage (Detected)
Resolved	No	Needs triage (Detected)
N/A (i.e.: new vulnerability)	No	Needs triage (Detected)

Deduplication process

When a pipeline contains jobs that produce multiple security reports of the same type, it is possible that the same vulnerability finding is present in multiple reports. This duplication is common when different scanners are used to increase coverage. The deduplication process allows you to maximize the vulnerability scanning coverage while reducing the number of findings you need to manage.

A finding is considered a duplicate of another finding when their scan type, location and identifiers are the same.

The scan type must match because each can have its own definition for the location of a vulnerability. For example, static analyzers are able to locate a file path and line number, whereas a container scanning analyzer uses the image name instead.

When comparing identifiers, GitLab does not compare CWE and WASC during deduplication because they are "type identifiers" and are used to classify groups of vulnerabilities. Including these identifiers results in many findings being incorrectly considered duplicates.

In a set of duplicated findings, the first occurrence of a finding is kept and the remaining are skipped. Security reports are processed in alphabetical file path order, and findings are processed sequentially in the order they appear in a report.

Deduplication examples

Example 1: matching identifiers and location, mismatching scan type.
- Finding
  - Scan type: sast
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CVE-2022-25510
- Other Finding
  - Scan type: secret_detection
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CVE-2022-25510
- Deduplication result: not duplicates because the scan type is different.
Example 2: matching location and scan type, mismatching type identifiers.
- Finding
  - Scan type: sast
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CWE-259
- Other Finding
  - Scan type: sast
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CWE-798
- Deduplication result: duplicates because CWE identifiers are ignored.
Example 3: matching scan type, location and identifiers.
- Finding
  - Scan type: container_scanning
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CVE-2022-25510, CWE-259
- Other Finding
  - Scan type: container_scanning
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CVE-2022-25510, CWE-798
- Deduplication result: duplicates because all criteria match, and type identifiers are ignored.

The examples above don't include the raw location values. Each scan type defines its own fingerprint_data, which is used to generate a SHA1 hash that is used as the location_fingerprint. You can find definitions for each scan type gitlab/lib/gitlab/ci/reports/security/locations and gitlab/ee/lib/gitlab/ci/reports/security/locations.