diff options
Diffstat (limited to 'doc/user/application_security/vulnerability_report')
-rw-r--r-- | doc/user/application_security/vulnerability_report/index.md | 13 | ||||
-rw-r--r-- | doc/user/application_security/vulnerability_report/pipeline.md | 24 |
2 files changed, 23 insertions, 14 deletions
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md index 15a287356f8..ba448d410ea 100644 --- a/doc/user/application_security/vulnerability_report/index.md +++ b/doc/user/application_security/vulnerability_report/index.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 --- @@ -44,7 +44,7 @@ At the project level, the Vulnerability Report also contains: To view the project-level vulnerability report: -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 **Security & Compliance > Vulnerability report**. ## Vulnerability Report actions @@ -57,6 +57,7 @@ From the Vulnerability Report you can: - [View an issue raised for a vulnerability](#view-issues-raised-for-a-vulnerability). - [Change the status of vulnerabilities](#change-status-of-vulnerabilities). - [Export details of vulnerabilities](#export-vulnerability-details). +- [Sort vulnerabilities by date](#sort-vulnerabilities-by-date-detected). - [Manually add a vulnerability finding](#manually-add-a-vulnerability-finding). ## Vulnerability Report filters @@ -186,6 +187,12 @@ Vulnerability records cannot be deleted, so a permanent record always remains. If a vulnerability is dismissed in error, reverse the dismissal by changing its status. +## Sort vulnerabilities by date detected + +By default, vulnerabilities are sorted by severity level, with the highest-severity vulnerabilities listed at the top. + +To sort vulnerabilities by the date each vulnerability was detected, click the "Detected" column header. + ## Export vulnerability details > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213014) in the Security Center (previously known as the Instance Security Dashboard) and project-level Vulnerability Report (previously known as the Project Security Dashboard) in GitLab 13.0. @@ -247,7 +254,7 @@ To undo this action, select a different status from the same menu. To add a new vulnerability finding from your project level Vulnerability Report page: -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 **Security & Compliance > Vulnerability Report**. 1. Select **Submit Vulnerability**. 1. Complete the fields and submit the form. 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`. |