Docs overhaul - Move docs of security scan results to its own page

app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue

@@ -97,7 +97,7 @@ export default {
       text: s__(
         'ciReport|New vulnerabilities are vulnerabilities that the security scan detects in the merge request that are different to existing vulnerabilities in the default branch.',
       ),
-      learnMorePath: helpPagePath('user/application_security/index', {
+      learnMorePath: helpPagePath('user/application_security/detect/security_scan_results', {
         anchor: 'merge-request',
       }),
     },

app/serializers/merge_request_widget_entity.rb

@@ -141,7 +141,7 @@ class MergeRequestWidgetEntity < Grape::Entity
   end
 
   expose :security_reports_docs_path do |merge_request|
-    help_page_path('user/application_security/index.md', anchor: 'merge-request')
+    help_page_path('user/application_security/detect/security_scan_results.md', anchor: 'merge-request')
   end
 
   expose :enabled_reports do |merge_request|

doc/ci/yaml/artifacts_reports.md

@@ -384,7 +384,7 @@ The collected Secret Detection report is uploaded to GitLab.
 GitLab can display the results of one or more reports in:
 
 - The merge request [secret scanning widget](../../user/application_security/secret_detection/pipeline/index.md).
-- The [pipeline security tab](../../user/application_security/index.md#pipeline-security-tab).
+- The [pipeline security tab](../../user/application_security/detect/security_scan_results.md).
 - The [security dashboard](../../user/application_security/security_dashboard/index.md).
 
 ## `artifacts:reports:terraform`

doc/development/sec/analyzer_development_guide.md

@@ -327,7 +327,7 @@ The [security-report-schema](https://gitlab.com/gitlab-org/security-products/sec
 
 #### Compatibility with report schema
 
-Security reports uploaded as [artifacts](../../user/application_security/index.md#all-tiers) to
+Security reports uploaded as artifacts to
 GitLab are [validated](../integrations/secure.md#report-validation) before being
 [ingested](security_report_ingestion_overview.md).
 

doc/development/sec/index.md

@@ -58,7 +58,7 @@ The results of the scans are exported as JSON reports that must comply with the
 After the data is available as a Report Artifact it can be processed by the GitLab Rails application to enable our security features, including:
 
 - [Security Dashboards](../../user/application_security/security_dashboard/index.md), Merge Request widget, Pipeline view, and so on.
-- [Interactions with vulnerabilities](../../user/application_security/index.md#interact-with-findings-and-vulnerabilities).
+- [Security scan results](../../user/application_security/detect/security_scan_results.md).
 - [Approval rules](../../user/application_security/index.md#security-approvals-in-merge-requests).
 
 Depending on the context, the security reports may be stored either in the database or stay as Report Artifacts for on-demand access.

doc/user/application_security/dast/index.md

@@ -56,8 +56,8 @@ target branches.
 
 ## View scan results
 
-Detected vulnerabilities appear in [merge requests](../index.md#merge-request), the [pipeline security tab](../index.md#pipeline-security-tab),
-and the [vulnerability report](../index.md#vulnerability-report).
+Detected vulnerabilities appear in [merge requests](../detect/security_scan_results.md#merge-request), the [pipeline security tab](../vulnerability_report/pipeline.md),
+and the [vulnerability report](../vulnerability_report/index.md).
 
 NOTE:
 A pipeline may consist of multiple jobs, including SAST and DAST scanning. If any job

doc/user/application_security/detect/security_scan_results.md

+---
+stage: Application Security Testing
+group: Static Analysis
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Security scan results
+
+GitLab provides security scan results both for developers and those responsible for triaging,
+analyzing, and remediating vulnerabilities.
+
+During feature development, security scan results are shown in the pipeline and merge request. For
+VS Code users, the
+[GitLab Workflow extension for VS Code](../../../editor_extensions/visual_studio_code/index.md) also
+shows security scan results. Identifying risks during development means they can be
+evaluated and remediated proactively.
+
+Vulnerabilities in the default branch are available in the vulnerability report, enabling
+efficient triaging, analysis, and remediation.
+
+## Merge request
+
+DETAILS:
+**Tier:** Free, Premium, Ultimate
+**Offering:** GitLab.com, Self-managed, GitLab Dedicated
+
+Output of all enabled application security tools is shown in a merge request widget. You can use
+this information to manage the risk of any issues identified in the source branch.
+
+### All tiers
+
+Merge requests which have run security scans let you know that the generated
+reports are available to download. To download a report, select
+**Download results**, and select the desired report.
+
+![Security widget](img/security_widget_v16_4.png)
+
+Security scans produce at least one of these [CI `artifacts:reports` types](../../../ci/yaml/artifacts_reports.md):
+
+- `artifacts:reports:api_fuzzing`
+- `artifacts:reports:container_scanning`
+- `artifacts:reports:coverage_fuzzing`
+- `artifacts:reports:dast`
+- `artifacts:reports:dependency_scanning`
+- `artifacts:reports:sast`
+- `artifacts:reports:secret_detection`
+
+In the Free tier, the reports above aren't parsed by GitLab. As a result, the widget does not change based on the results of the security scans.
+
+### Ultimate
+
+A merge request contains a security widget which displays a summary of the _new_ results. New results are determined by comparing the findings of the merge request against the findings of the most recent completed pipeline (`success`, `failed`, `canceled` or `skipped`) for the commit when the feature branch was created from the target branch.
+
+GitLab checks the last 10 pipelines for the commit when the feature branch was created from the target branch to find one with security reports to use in comparison logic. If security scans have not run for the last 10 completed pipelines in the target branch when the feature branch was created, there is no base for comparison. The vulnerabilities from the merge request findings are listed as _new_ in the merge request security widget. We recommend you run a scan of the `default` (target) branch before enabling feature branch scans for your developers.
+
+The MR security widget considers all supported pipeline sources (based on the [`CI_PIPELINE_SOURCE` variable](../../../ci/variables/predefined_variables.md)) when comparing results from both the source and target branches when determining if a merge request requires approval. Pipeline sources `webide` and `parent_pipeline` are not supported.
+
+The merge request security widget displays only a subset of the vulnerabilities in the generated JSON artifact because it contains both new and existing findings.
+
+From the merge request security widget, select **Expand** to unfold the widget, displaying any new and no longer detected (removed) findings by scan type.
+
+For each security report type, the widget displays the first 25 added and 25 fixed findings, sorted by severity.
+This is determined by comparing the security reports from the source branch and target branch pipelines.
+
+As an example, consider two pipelines with these scan results:
+
+- The source branch pipeline detects two vulnerabilities identified as `V1` and `V2`.
+- The target branch pipeline detects two vulnerabilities identified as `V1` and `V3`.
+- `V2` will show on the merge request widget as "added".
+- `V3` will show on the merge request widget as "fixed".
+- `V1` exists on both branches and is not shown on the merge request widget.
+
+To see all findings on the source branch of the merge request, select **View full report** to go directly to the **Security** tab in the latest source branch pipeline.
+
+![Security scanning results in a merge request](img/mr_security_scanning_results_v14_3.png)

doc/user/application_security/get-started-security.md

@@ -91,7 +91,7 @@ and preventing the introduction of new ones.
 For more information, see:
 
 - [View the vulnerability report](vulnerability_report/index.md)
-- [View security findings in merge requests](index.md#view-security-scan-information)
+- [View security findings in merge requests](detect/security_scan_results.md#merge-request)
 - [View the Security Dashboard](security_dashboard/index.md)
 - [Labels](../project/labels.md)
 - [Issue boards](../project/issue_board.md)

doc/user/application_security/index.md

@@ -122,98 +122,6 @@ restricted to the [`developer` role](../permissions.md#roles).
 
 The [security report](../../development/integrations/secure.md#report) artifact generated by the secure analyzer contains all findings it discovers on the target branch, regardless of whether they were previously found, dismissed, or completely new (it puts in everything that it finds).
 
-## View security scan information
-
-Security scan information appears in multiple locations and formats:
-
-- Merge request
-- Pipeline security tab
-- Security dashboard
-- Vulnerability report
-- GitLab Workflow extension for VS Code
-
-### Merge request
-
-DETAILS:
-**Tier:** Free, Premium, Ultimate
-**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-
-Output of all enabled application security tools is shown in a merge request widget. You can use
-this information to manage the risk of any issues identified in the source branch.
-
-#### All tiers
-
-Merge requests which have run security scans let you know that the generated
-reports are available to download. To download a report, select
-**Download results**, and select the desired report.
-
-![Security widget](img/security_widget_v16_4.png)
-
-Security scans produce at least one of these [CI `artifacts:reports` types](../../ci/yaml/artifacts_reports.md):
-
-- `artifacts:reports:api_fuzzing`
-- `artifacts:reports:container_scanning`
-- `artifacts:reports:coverage_fuzzing`
-- `artifacts:reports:dast`
-- `artifacts:reports:dependency_scanning`
-- `artifacts:reports:sast`
-- `artifacts:reports:secret_detection`
-
-In the Free tier, the reports above aren't parsed by GitLab. As a result, the widget does not change based on the results of the security scans.
-
-#### Ultimate
-
-A merge request contains a security widget which displays a summary of the _new_ results. New results are determined by comparing the findings of the merge request against the findings of the most recent completed pipeline (`success`, `failed`, `canceled` or `skipped`) for the commit when the feature branch was created from the target branch.
-
-GitLab checks the last 10 pipelines for the commit when the feature branch was created from the target branch to find one with security reports to use in comparison logic. If security scans have not run for the last 10 completed pipelines in the target branch when the feature branch was created, there is no base for comparison. The vulnerabilities from the merge request findings are listed as _new_ in the merge request security widget. We recommend you run a scan of the `default` (target) branch before enabling feature branch scans for your developers.
-
-The MR security widget considers all supported pipeline sources (based on the [`CI_PIPELINE_SOURCE` variable](../../ci/variables/predefined_variables.md)) when comparing results from both the source and target branches when determining if a merge request requires approval. Pipeline sources `webide` and `parent_pipeline` are not supported.
-
-The merge request security widget displays only a subset of the vulnerabilities in the generated JSON artifact because it contains both new and existing findings.
-
-From the merge request security widget, select **Expand** to unfold the widget, displaying any new and no longer detected (removed) findings by scan type.
-
-For each security report type, the widget displays the first 25 added and 25 fixed findings, sorted by severity.
-This is determined by comparing the security reports from the source branch and target branch pipelines.
-
-As an example, consider two pipelines with these scan results:
-
-- The source branch pipeline detects two vulnerabilities identified as `V1` and `V2`.
-- The target branch pipeline detects two vulnerabilities identified as `V1` and `V3`.
-- `V2` will show on the merge request widget as "added".
-- `V3` will show on the merge request widget as "fixed".
-- `V1` exists on both branches and is not shown on the merge request widget.
-
-To see all findings on the source branch of the merge request, select **View full report** to go directly to the **Security** tab in the latest source branch pipeline.
-
-![Security scanning results in a merge request](img/mr_security_scanning_results_v14_3.png)
-
-### Pipeline security tab
-
-A pipeline's security tab lists all findings from the security reports in the pipeline's
-job artifacts. For more information see
-[Vulnerabilities in a pipeline](vulnerability_report/pipeline.md).
-
-### Security dashboard
-
-The security dashboard shows the vulnerabilities on a project's default branch. Data is updated every 24 hours. Vulnerability count updates resulting from any feature branches introducing new vulnerabilities that are merged to default are included after the daily data refresh.
-
-For more details, see [Security Dashboard](security_dashboard/index.md).
-
-### Vulnerability report
-
-The vulnerability report shows the results of the last completed pipeline on the default branch. It is updated on every pipeline completion. All detected vulnerabilities are shown and any previous ones that are no longer detected in the latest scan. Vulnerabilities that are no longer detected may have been remediated or otherwise removed and can be marked as `Resolved` after proper verification. Vulnerabilities that are no longer detected are denoted with an icon for filtering and review.
-
-By default, the vulnerability report does not show vulnerabilities of `dismissed` or `resolved` status so you can focus on open vulnerabilities. You can change the Status filter to see these.
-
-[Read more about the Vulnerability report](vulnerability_report/index.md).
-
-### GitLab Workflow extension for VS Code
-
-You can now see security findings directly in Visual Studio Code (VS Code) using [GitLab Workflow extension for VS Code](../../editor_extensions/visual_studio_code/index.md), just as you would in a merge request.
-
-For more details, see [extension page](https://marketplace.visualstudio.com/items?itemName=gitlab.gitlab-workflow#security-findings).
-
 ## Security approvals in merge requests
 
 > - [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357300) the Vulnerability-Check feature in GitLab 15.0.
@@ -251,30 +159,6 @@ Validation depends on the schema version declared in the security report artifac
 
 You can always find supported and deprecated schema versions in the [source code](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/parsers/security/validators/schema_validator.rb).
 
-## Interact with findings and vulnerabilities
-
-You can interact with the results of the security scanning tools in several locations:
-
-- [Scan information in merge requests](#merge-request)
-- [Project Security Dashboard](security_dashboard/index.md#project-security-dashboard)
-- [Security pipeline tab](vulnerability_report/pipeline.md)
-- [Group Security Dashboard](security_dashboard/index.md#group-security-dashboard)
-- [Security Center](security_dashboard/index.md#security-center)
-- [Vulnerability Report](vulnerability_report/index.md)
-- [Vulnerability Pages](vulnerabilities/index.md)
-- [Dependency List](dependency_list/index.md)
-
-For more details about which findings or vulnerabilities you can view in each of those locations,
-select the respective link. Each page details the ways in which you can interact with the findings
-and vulnerabilities. As an example, in most cases findings start out as a _detected_ status.
-
-You have the option to:
-
-- Change the status.
-- Create an issue.
-- Link it to an existing issue.
-- [Resolve the vulnerability](vulnerabilities/index.md#resolve-a-vulnerability), if a solution is known.
-
 ## Security scanning configuration tips
 
 Each GitLab security scanning tool has a default

doc/user/application_security/sast/customize_rulesets.md

@@ -30,8 +30,8 @@ You can disable predefined rules for any SAST analyzer.
 When you disable a rule:
 
 - Most analyzers still scan for the vulnerability. The results are removed as a processing step after the scan completes, and they don't appear in the [`gl-sast-report.json` artifact](index.md#download-a-sast-report).
-- Findings for the disabled rule no longer appear in the [pipeline security tab](../index.md#pipeline-security-tab).
-- Existing findings for the disabled rule on the default branch are marked as [`No longer detected`](../vulnerability_report/index.md#activity-filter) in the [vulnerability report](../index.md#vulnerability-report).
+- Findings for the disabled rule no longer appear in the [pipeline security tab](../vulnerability_report/pipeline.md).
+- Existing findings for the disabled rule on the default branch are marked as [`No longer detected`](../vulnerability_report/index.md#activity-filter) in the [vulnerability report](../vulnerability_report/index.md).
 
 The Semgrep-based analyzer handles disabled rules differently:
 

doc/user/application_security/secret_detection/pipeline/index.md

@@ -18,7 +18,7 @@ You can run scans and view [pipeline secret detection JSON report artifacts](../
 
 With GitLab Ultimate, pipeline secret detection results are also processed so you can:
 
-- See them in the [merge request widget](../../index.md#merge-request), [pipeline security report](../../vulnerability_report/pipeline.md), and [vulnerability report](../../vulnerability_report/index.md) UIs.
+- See them in the [merge request widget](../../detect/security_scan_results.md#merge-request), [pipeline security report](../../vulnerability_report/pipeline.md), and [vulnerability report](../../vulnerability_report/index.md) UIs.
 - Use them in approval workflows.
 - Review them in the security dashboard.
 - [Automatically respond](../automatic_response.md) to leaks in public repositories.

doc/user/application_security/troubleshooting_application_security.md

@@ -199,7 +199,7 @@ Instructions are available in the [legacy template project](https://gitlab.com/g
 In these circumstances, that the job succeeds is the default behavior. The job's status indicates
 success or failure of the analyzer itself. Analyzer results are displayed in the
 [job logs](../../ci/jobs/job_logs.md#expand-and-collapse-job-log-sections),
-[merge request widget](index.md#merge-request), or
+[merge request widget](detect/security_scan_results.md#merge-request), or
 [security dashboard](security_dashboard/index.md).
 
 ## Error: job `is used for configuration only, and its script should not be executed`

doc/user/application_security/vulnerabilities/index.md

@@ -264,7 +264,7 @@ Vulnerability Resolution in a merge request sometimes cannot generate a suggeste
   - A new request may succeed, so you can try to resolve the vulnerability again.
   - If you continue to see these errors, contact GitLab for assistance.
 - **Resolution target could not be found in the merge request, unable to create suggestion:**
-  - This error may occur when the target branch has not run a full security scan pipeline. See the [merge request documentation](../index.md#ultimate).
+  - This error may occur when the target branch has not run a full security scan pipeline. See the [merge request documentation](../detect/security_scan_results.md#merge-request).
 
 ## Vulnerability code flow
 

doc/user/project/merge_requests/widgets.md

@@ -93,4 +93,4 @@ see the status of these checks in merge requests
 
 If you enable any application security scanning tools, GitLab shows the results in the security
 scanning widget. For more information, see
-[security scanning output in merge request widget](../../application_security/index.md#merge-request).
+[security scanning output in merge request widget](../../application_security/detect/security_scan_results.md#merge-request).

ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue

@@ -356,7 +356,7 @@ export default {
     options: { title: i18n.helpPopoverTitle },
     content: {
       text: i18n.helpPopoverContent,
-      learnMorePath: helpPagePath('user/application_security/index', {
+      learnMorePath: helpPagePath('user/application_security/detect/security_scan_results', {
         anchor: 'ultimate',
       }),
     },

spec/frontend/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports_spec.js

@@ -44,7 +44,8 @@ describe('vue_merge_request_widget/widgets/security_reports/mr_widget_security_r
     it('displays the help popover', () => {
       expect(findWidget().props('helpPopover')).toEqual({
         content: {
-          learnMorePath: '/help/user/application_security/index#merge-request',
+          learnMorePath:
+            '/help/user/application_security/detect/security_scan_results#merge-request',
           text: 'New vulnerabilities are vulnerabilities that the security scan detects in the merge request that are different to existing vulnerabilities in the default branch.',
         },
         options: {