Vulnerabilities in a pipeline

DETAILS: Tier: Ultimate Offering: SaaS, self-managed

All enabled security analyzers run in the pipeline and output their results as artifacts. These artifacts are processed, including deduplication, and the results are listed on the pipeline Security tab. By identifying vulnerability findings in a pipeline, you can address the risks proactively.

The following criteria apply to the pipeline security tab:

The results of only successful security scan jobs are shown. For example, if a pipeline contains SAST and DAST jobs, but the DAST job fails, only the SAST results are shown.
If the pipeline has a blocking manual job, the pipeline waits for the manual job, and the vulnerabilities cannot be displayed if the blocking manual job did not run.
Findings have an expiry period. Expired findings are not shown on the pipeline security tab. For details, see Retention period for findings.

View vulnerabilities in a pipeline

To view vulnerabilities in a pipeline:

On the left sidebar, select Search or go to and find your project.
Select Build > Pipelines.
Select the pipeline.
Select the Security tab.

Scan details

The Scan details section 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.

Downloading security scan results

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:

On the left sidebar, select Search or go to and find your project.
Select Build > Pipelines.
Select the pipeline.
Select the Security tab.
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

Findings present in the source branch are listed in descending order of severity. You can filter the list of findings by severity and tool. You can also download the results of the security scans, for analysis outside GitLab.

Findings that are dismissed are hidden by default. To see these findings, turn off the Hide dismissed toggle.

For each finding you can:

Get more information about the finding.
Create an issue for the finding.
Dismiss the finding.

When you merge the merge request's branch into the target branch, all reported findings are in the vulnerability report. Scan results in pipelines executed on the default branch are incorporated after the pipeline finishes, according to the following table:

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 (New vulnerability)	No	Needs triage (Detected)

Retention period for findings

Introduced in GitLab 15.5.

Findings are no longer available:

When the related CI job artifact expires.
90 days after the pipeline is created, even if the related CI job artifacts are locked.

To view findings, either:

Run a new pipeline.
Download the related CI job artifacts if they are available.

NOTE: This does not apply for the vulnerabilities existing on the default branch.

Change status of findings

Introduced in GitLab 16.7 with a flag named pipeline_security_dashboard_graphql. Disabled by default.

FLAG: On self-managed GitLab, by default this feature is not available. To make it available, an administrator can enable the feature flag named pipeline_security_dashboard_graphql. On GitLab.com, this feature is not available.

To change the status of findings to Dismiss or Needs triage:

On the left sidebar, select Search or go to and find your project.
Select Build > Pipelines.
Select a pipeline and select the Security tab.
To select:
- One or more findings, select the checkbox beside each finding.
- All findings on the page, select the checkbox in the table header.
In the Set status dropdown list, select the desired status.
If the Dismiss status is chosen, select the desired reason in the Set dismissal reason dropdown list.
In the Add a comment input, you can provide a comment. For the Dismiss status, a comment is required.
Select Change status.

The status of the selected findings is updated and the content of the security tab is refreshed.

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, but can also exist in a single report. 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 one or more of its 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 would result in many findings being incorrectly considered duplicates. Two findings are considered unique if none of their identifiers match.

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 an identifier.
- Finding
  - Scan type: container_scanning
  - Location fingerprint: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
  - Identifiers: CVE-2019-12345, 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. Only one identifier needs to match, in this case CVE-2022-25510.

You can find definitions for each scan type gitlab/lib/gitlab/ci/reports/security/locations and gitlab/ee/lib/gitlab/ci/reports/security/locations.

For instance, for container_scanning type the location is defined by Docker image name without tag. However if the image tag contains at least one letter and/or is longer than 8 characters, it isn't considered a duplicate. So, locations registry.gitlab.com/group-name/project-name/image1:12345019:libcrypto3 and registry.gitlab.com/group-name/project-name/image1:libcrypto3 are treated as identical while registry.gitlab.com/group-name/project-name/image1:v19202021:libcrypto3 and registry.gitlab.com/group-name/project-name/image1:libcrypto3 are considered different.