Add latest changes from gitlab-org/gitlab@master

doc/development/sec/_index.md

@@ -8,7 +8,7 @@ title: Sec section development guidelines
 The Sec section is responsible for GitLab application security features, the "Sec" part of
 DevSecOps. Development guides that are specific to the Sec section are listed here.
 
-See [Terminology](../../user/application_security/terminology/index.md) for an overview of our shared terminology.
+See [Terminology](../../user/application_security/terminology/_index.md) for an overview of our shared terminology.
 
 ## Architecture
 
@@ -44,21 +44,21 @@ flowchart LR
 ### Scanning
 
 The scanning part is responsible for finding vulnerabilities in given resources, and exporting results.
-The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/index.md#analyzer), which can be found in our [Analyzers subgroup](https://gitlab.com/gitlab-org/security-products/analyzers).
-The Analyzers are wrappers around security tools called [Scanners](../../user/application_security/terminology/index.md#scanner), developed internally or externally, to integrate them into GitLab.
+The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/_index.md#analyzer), which can be found in our [Analyzers subgroup](https://gitlab.com/gitlab-org/security-products/analyzers).
+The Analyzers are wrappers around security tools called [Scanners](../../user/application_security/terminology/_index.md#scanner), developed internally or externally, to integrate them into GitLab.
 The Analyzers are mainly written in Go.
 
 Some 3rd party integrators also make additional Scanners available by following our [integration documentation](../integrations/secure.md), which leverages the same architecture.
 
-The results of the scans are exported as JSON reports that must comply with the [Secure report format](../../user/application_security/terminology/index.md#secure-report-format) and are uploaded as [CI/CD Job Report artifacts](../../ci/jobs/job_artifacts.md) to make them available for processing after the pipelines completes.
+The results of the scans are exported as JSON reports that must comply with the [Secure report format](../../user/application_security/terminology/_index.md#secure-report-format) and are uploaded as [CI/CD Job Report artifacts](../../ci/jobs/job_artifacts.md) to make them available for processing after the pipelines completes.
 
 ### Processing, visualization, and management
 
 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.
+- [Security Dashboards](../../user/application_security/security_dashboard/_index.md), Merge Request widget, Pipeline view, and so on.
 - [Security scan results](../../user/application_security/detect/security_scan_results.md).
-- [Approval rules](../../user/application_security/index.md#security-approvals-in-merge-requests).
+- [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.
 
@@ -77,7 +77,7 @@ If you are working with CI/CD templates, read the [development guide for GitLab
 Within analyzer JSON reports, the [`identifiers` field](../integrations/secure.md#identifiers) contains a collection of types and categories by which
 a vulnerability can be described (that is, a CWE family).
 
-The first item in the `identifiers` collection is known as the [primary identifier](../../user/application_security/terminology/index.md#primary-identifier),
+The first item in the `identifiers` collection is known as the [primary identifier](../../user/application_security/terminology/_index.md#primary-identifier),
 a critical component to both describing and tracking vulnerabilities.
 
 In most other cases, the `identifiers` collection is unordered, where the remaining secondary identifiers act as metadata for grouping vulnerabilities
@@ -88,7 +88,7 @@ Because our processing logic relies on generating a delta of two different vulne
 
 ![Screenshot of primary identifier mismatch in MR widget](img/primary_identifier_changed_v15_6.png)
 
-After being [merged](../integrations/secure.md#tracking-and-merging-vulnerabilities), the previous vulnerability is listed as "remediated" and the introduced as ["detected"](../../user/application_security/vulnerabilities/index.md#vulnerability-status-values).
+After being [merged](../integrations/secure.md#tracking-and-merging-vulnerabilities), the previous vulnerability is listed as "remediated" and the introduced as ["detected"](../../user/application_security/vulnerabilities/_index.md#vulnerability-status-values).
 
 ### Guiding principles for ensuring primary identifier stability
 

doc/development/sec/analyzer_development_guide.md

@@ -38,7 +38,7 @@ Analyzers are shipped as Docker images. For example, to run the
        registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest /analyzer run
    ```
 
-1. The Docker container generates a report in the mounted project directory with a report filename corresponding to the analyzer category. For example, [SAST](../../user/application_security/sast/index.md) generates a file named `gl-sast-report.json`.
+1. The Docker container generates a report in the mounted project directory with a report filename corresponding to the analyzer category. For example, [SAST](../../user/application_security/sast/_index.md) generates a file named `gl-sast-report.json`.
 
 ## Analyzers development
 
@@ -79,13 +79,13 @@ go build -o analyzer
 
 ### Execution criteria
 
-[Enabling SAST](../../user/application_security/sast/index.md#configure-sast-in-your-cicd-yaml) requires including a pre-defined [template](https://gitlab.com/gitlab-org/gitlab/-/blob/ee4d473eb9a39f2f84b719aa0ca13d2b8e11dc7e/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) to your GitLab CI/CD configuration.
+[Enabling SAST](../../user/application_security/sast/_index.md#configure-sast-in-your-cicd-yaml) requires including a pre-defined [template](https://gitlab.com/gitlab-org/gitlab/-/blob/ee4d473eb9a39f2f84b719aa0ca13d2b8e11dc7e/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) to your GitLab CI/CD configuration.
 
 The following independent criteria determine which analyzer needs to be run on a project:
 
 1. The SAST template uses [`rules:exists`](../../ci/yaml/_index.md#rulesexists) to determine which analyzer will be run based on the presence of certain files. For example, the Brakeman analyzer [runs when there are](https://gitlab.com/gitlab-org/gitlab/-/blob/ee4d473eb9a39f2f84b719aa0ca13d2b8e11dc7e/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L60) `.rb` files and a `Gemfile`.
 1. Each analyzer runs a customizable [match interface](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/blob/master/search/search.go) before it performs the actual analysis. For example: [Flawfinder checks for C/C++ files](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/blob/f972ac786268fb649553056a94cda05cdc1248b2/plugin/plugin.go#L14).
-1. For some analyzers that run on generic file extensions, there is a check based on a CI/CD variable. For example: Kubernetes manifests are written in YAML, so [Kubesec](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) runs only when [`SCAN_KUBERNETES_MANIFESTS` is set to true](../../user/application_security/sast/index.md#enabling-kubesec-analyzer).
+1. For some analyzers that run on generic file extensions, there is a check based on a CI/CD variable. For example: Kubernetes manifests are written in YAML, so [Kubesec](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) runs only when [`SCAN_KUBERNETES_MANIFESTS` is set to true](../../user/application_security/sast/_index.md#enabling-kubesec-analyzer).
 
 Step 1 helps prevent wastage of compute quota that would be spent running analyzers not suitable for the project. However, due to [technical limitations](https://gitlab.com/gitlab-org/gitlab/-/issues/227632), it cannot be used for large projects. Therefore, step 2 acts as final check to ensure a mismatched analyzer is able to exit early.
 
@@ -487,7 +487,7 @@ This process only applies to the images used in versions of GitLab matching the
 - the `MAJOR` image tag (e.g.: `4`)
 - the `latest` image tag
 
-The implementation of the rebuild process may vary [depending on the project](../../user/application_security/index.md#vulnerability-scanner-maintenance), though a shared CI configuration is available in our [development ci-templates project](https://gitlab.com/gitlab-org/security-products/ci-templates/-/blob/master/includes-dev/docker.yml) to help achieving this.
+The implementation of the rebuild process may vary [depending on the project](../../user/application_security/_index.md#vulnerability-scanner-maintenance), though a shared CI configuration is available in our [development ci-templates project](https://gitlab.com/gitlab-org/security-products/ci-templates/-/blob/master/includes-dev/docker.yml) to help achieving this.
 
 ## Security and Build fixes of Go
 
@@ -564,8 +564,8 @@ First, create an new issue for a release with a script from this repo: `./script
 This issue will guide you through the whole release process. In general, you have to perform the following tasks:
 
 - Check the list of supported technologies in GitLab documentation.
-  - [Supported languages in SAST](../../user/application_security/sast/index.md#supported-languages-and-frameworks)
-  - [Supported languages in DS](../../user/application_security/dependency_scanning/index.md#supported-languages-and-package-managers)
+  - [Supported languages in SAST](../../user/application_security/sast/_index.md#supported-languages-and-frameworks)
+  - [Supported languages in DS](../../user/application_security/dependency_scanning/_index.md#supported-languages-and-package-managers)
   - [Supported languages in LS](../../user/compliance/license_scanning_of_cyclonedx_files/_index.md#supported-languages-and-package-managers)
 
 - Check that CI **_job definitions are still accurate_** in vendored CI/CD templates and **_all of the ENV vars are propagated_** to the Docker containers upon `docker run` per tool.

doc/development/sec/generate_test_vulnerabilities.md

@@ -5,7 +5,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
 title: Generate test vulnerabilities
 ---
 
-You can generate test vulnerabilities for the [Vulnerability Report](../../user/application_security/vulnerability_report/index.md) to test GitLab
+You can generate test vulnerabilities for the [Vulnerability Report](../../user/application_security/vulnerability_report/_index.md) to test GitLab
 vulnerability management features without running a pipeline.
 
 1. Sign in to GitLab.

doc/development/sec/security_report_ingestion_overview.md

@@ -59,7 +59,7 @@ An instance of the `Vulnerabilities::Remediation` class. A remediation is repres
 Assumptions:
 
 - Project uses GitLab CI
-- Project uses [security scanning tools](../../user/application_security/index.md)
+- Project uses [security scanning tools](../../user/application_security/_index.md)
 - No Vulnerabilities are present in the database
 - All pipelines perform security scans
 
@@ -119,5 +119,5 @@ This style of creation was intended to be fast and seamless, but has proven diff
 The "No longer detected" badge on the vulnerability report is displayed if the `Vulnerability` record has `resolved_on_default_branch: true`.
 This is set by `Security::Ingestion::MarkAsResolvedService` when a pipeline runs on the default branch. Vulnerabilities which have
 `resolved_on_default_branch: false` and _are not_ present in the pipeline scan results are marked as resolved.
-[Secret Detection](../../user/application_security/secret_detection/index.md) and [manual](../../user/application_security/vulnerability_report/index.md#manually-add-a-vulnerability)
+[Secret Detection](../../user/application_security/secret_detection/_index.md) and [manual](../../user/application_security/vulnerability_report/_index.md#manually-add-a-vulnerability)
 vulnerabilities are excluded from this process.

doc/development/sec/token_revocation_api.md

@@ -44,7 +44,7 @@ All endpoints may return these responses:
 Returns the valid `type` values for use in the `revoke_tokens` endpoint.
 
 NOTE:
-These values match the concatenation of [the `secrets` analyzer's](../../user/application_security/secret_detection/pipeline/index.md)
+These values match the concatenation of [the `secrets` analyzer's](../../user/application_security/secret_detection/pipeline/_index.md)
 [primary identifier](../integrations/secure.md#identifiers) by means
 of concatenating the `primary_identifier.type` and `primary_identifier.value`.
 For example, the value `gitleaks_rule_id_gitlab_personal_access_token` matches the following finding identifier: