summaryrefslogtreecommitdiff
path: root/doc/user/application_security/vulnerability_report/pipeline.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/application_security/vulnerability_report/pipeline.md')
-rw-r--r--doc/user/application_security/vulnerability_report/pipeline.md24
1 files changed, 13 insertions, 11 deletions
diff --git a/doc/user/application_security/vulnerability_report/pipeline.md b/doc/user/application_security/vulnerability_report/pipeline.md
index 32916f4c9c7..7faf273515c 100644
--- a/doc/user/application_security/vulnerability_report/pipeline.md
+++ b/doc/user/application_security/vulnerability_report/pipeline.md
@@ -1,6 +1,6 @@
---
type: reference, howto
-stage: Secure
+stage: Govern
group: Threat Insights
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
To view vulnerabilities in a pipeline:
-1. On the top bar, select **Menu > Projects** and find your project.
+1. On the top bar, select **Main menu > Projects** and find your project.
1. On the left sidebar, select **CI/CD > Pipelines**.
1. From the list, select the pipeline you want to check for vulnerabilities.
1. Select the **Security** tab.
@@ -26,7 +26,7 @@ For example, if a pipeline contains DAST and SAST jobs, but the DAST job fails b
The pipeline vulnerability report only shows results contained in the security report artifacts. This report differs from
the [Vulnerability Report](index.md), which contains cumulative results of all successful jobs, and from the merge request
-[security widget](../#view-security-scan-information-in-merge-requests), which combines the branch results with
+[security widget](../index.md#view-security-scan-information-in-merge-requests), which combines the branch results with
cumulative results.
Before GitLab displays results, the vulnerability findings in all pipeline reports are [deduplicated](#deduplication-process).
@@ -35,7 +35,7 @@ Before GitLab displays results, the vulnerability findings in all pipeline repor
**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](../terminology/#scan-type-report-type) artifact present in
+GitLab displays one row of information for each [scan type](../terminology/index.md#scan-type-report-type) artifact present in
the pipeline.
Note that each scan type's total number of vulnerabilities includes dismissed findings. If the number of findings
@@ -83,11 +83,11 @@ incorporated once the pipeline finishes.
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
+increase coverage, but can also exist within 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](../terminology/#scan-type-report-type),
-[location](../terminology/#location-fingerprint) and
+A finding is considered a duplicate of another finding when their [scan type](../terminology/index.md#scan-type-report-type),
+[location](../terminology/index.md#location-fingerprint), and one or more of its
[identifiers](../../../development/integrations/secure.md#identifiers) are the same.
The scan type must match because each can have its own definition for the location of a vulnerability. For example,
@@ -95,8 +95,9 @@ static analyzers are able to locate a file path and line number, whereas a conta
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.
+"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
@@ -124,16 +125,17 @@ appear in a report.
- Location fingerprint: `adc83b19e793491b1c6ea0fd8b46cd9f32e592fc`
- Identifiers: CWE-798
- Deduplication result: duplicates because `CWE` identifiers are ignored.
-- Example 3: matching scan type, location and identifiers.
+- Example 3: matching scan type, location and an identifier.
- Finding
- Scan type: `container_scanning`
- Location fingerprint: `adc83b19e793491b1c6ea0fd8b46cd9f32e592fc`
- - Identifiers: CVE-2022-25510, CWE-259
+ - 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.
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`.