Broke out the 2 kinds of detection into their own sub-pages

Replace 'Post-receive' with 'Pipeline' per the issue discussion

Replace 'Secret Detection' with 'Pipeline Secret Detection'

app/services/security/ci_configuration/secret_detection_create_service.rb

@@ -22,7 +22,7 @@ def message
       end
 
       def description
-        _('Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings) to customize Secret Detection settings.')
+        _('Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#configuration) to customize Secret Detection settings.')
       end
 
       def name

doc/ci/yaml/artifacts_reports.md

@@ -376,12 +376,12 @@ For more information, see:
 
 ## `artifacts:reports:secret_detection`
 
-The `secret-detection` report collects [detected secrets](../../user/application_security/secret_detection/index.md).
+The `secret-detection` report collects [detected secrets](../../user/application_security/secret_detection/pipeline/index.md).
 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/index.md).
+- 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 [security dashboard](../../user/application_security/security_dashboard/index.md).
 

doc/development/features_inside_dot_gitlab.md

@@ -17,5 +17,5 @@ When implementing new features, refer to these existing features to avoid confli
 - [Customize Auto DevOps Helm Values](../topics/autodevops/customize.md#customize-helm-chart-values): `.gitlab/auto-deploy-values.yaml`.
 - [Insights](../user/project/insights/index.md#configure-project-insights): `.gitlab/insights.yml`.
 - [Service Desk Templates](../user/project/service_desk/configure.md#customize-emails-sent-to-the-requester): `.gitlab/service_desk_templates/`.
-- [Secret Detection Custom Rulesets](../user/application_security/secret_detection/index.md#disable-predefined-analyzer-rules): `.gitlab/secret-detection-ruleset.toml`
+- [Secret Detection Custom Rulesets](../user/application_security/secret_detection/pipeline/index.md#disable-predefined-analyzer-rules): `.gitlab/secret-detection-ruleset.toml`
 - [Static Analysis Custom Rulesets](../user/application_security/sast/customize_rulesets.md#create-the-configuration-file): `.gitlab/sast-ruleset.toml`

doc/development/sec/token_revocation_api.md

@@ -45,7 +45,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/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:

doc/topics/autodevops/stages.md

@@ -220,7 +220,7 @@ For more information, see
 ## Auto Secret Detection
 
 > - Introduced in GitLab 13.1.
-> - Select functionality [made available](../../user/application_security/secret_detection/index.md#features-per-tier) in all tiers in GitLab 13.3
+> - Select functionality [made available](../../user/application_security/secret_detection/pipeline/index.md#requirements) in all tiers in GitLab 13.3
 
 Secret Detection uses the
 [Secret Detection Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) to run Secret Detection on the current code, and checks for leaked secrets. Auto Secret Detection requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above.

doc/user/application_security/configuration/index.md

@@ -64,9 +64,9 @@ You can configure the following security controls:
     [Enable Container Scanning through an automatic merge request](../container_scanning/index.md#enable-container-scanning-through-an-automatic-merge-request).
 - [Operational Container Scanning](../../clusters/agent/vulnerabilities.md)
   - Can be configured by adding a configuration block to your agent configuration. For more details, read [Operational Container Scanning](../../clusters/agent/vulnerabilities.md#enable-operational-container-scanning).
-- [Secret Detection](../secret_detection/index.md)
+- [Secret Detection](../secret_detection/pipeline/index.md)
   - Select **Configure with a merge request** to create a merge request with the changes required to
-    enable Secret Detection. For more details, read [Use an automatically configured merge request](../secret_detection/index.md#use-an-automatically-configured-merge-request).
+    enable Secret Detection. For more details, read [Use an automatically configured merge request](../secret_detection/pipeline/index.md#use-an-automatically-configured-merge-request).
 - [API Fuzzing](../api_fuzzing/index.md)
   - Select **Enable API Fuzzing** to use API Fuzzing for the current project. For more details, read [API Fuzzing](../../../user/application_security/api_fuzzing/configuration/enabling_the_analyzer.md).
 - [Coverage Fuzzing](../coverage_fuzzing/index.md)

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

@@ -34,9 +34,9 @@ After you've gotten familiar with how scanning works, you can then choose to:
    - That uses your organization's typical programming languages and technologies, because some scanning features work differently across languages.
    - Where you can try out new settings, like required approvals, without interrupting your team's daily work.
      You could create a copy of a higher-traffic project for testing, or select a project that's not as busy.
-1. Create a merge request to [enable Secret Detection](secret_detection/index.md#enable-secret-detection) and [enable Dependency Scanning](dependency_scanning/index.md#configuration)
+1. Create a merge request to [enable Secret Detection](secret_detection/pipeline/index.md#enabling-the-analyzer) and [enable Dependency Scanning](dependency_scanning/index.md#configuration)
    to identify any leaked secrets and vulnerable packages in that project.
-   - Security scanners run in your project's [CI/CD pipelines](../../ci/pipelines/index.md). Creating a merge request to update your [`.gitlab-ci.yml`](../../ci/index.md#the-gitlab-ciyml-file) helps you check how the scanners work with your project before they start running in every pipeline. In the merge request, you can change relevant [Secret Detection settings](secret_detection/index.md#configure-scan-settings) or [Dependency Scanning settings](dependency_scanning/index.md#available-cicd-variables) to accommodate your project's layout or configuration. For example, you might choose to exclude a directory of third-party code from scanning.
+   - Security scanners run in your project's [CI/CD pipelines](../../ci/pipelines/index.md). Creating a merge request to update your [`.gitlab-ci.yml`](../../ci/index.md#the-gitlab-ciyml-file) helps you check how the scanners work with your project before they start running in every pipeline. In the merge request, you can change relevant [Secret Detection settings](secret_detection/pipeline/index.md#configuration) or [Dependency Scanning settings](dependency_scanning/index.md#available-cicd-variables) to accommodate your project's layout or configuration. For example, you might choose to exclude a directory of third-party code from scanning.
    - After you merge this MR to your [default branch](../project/repository/branches/default.md), the system creates a baseline scan. This scan identifies which vulnerabilities already exist on the default branch so [merge requests](../project/merge_requests/index.md) can highlight only newly-introduced problems. Without a baseline scan, merge requests display every
      vulnerability in the branch, even if the vulnerability already exists on the default branch.
 1. Let your team get comfortable with [viewing security findings in merge requests](index.md#view-security-scan-information) and the [vulnerability report](vulnerability_report/index.md).

doc/user/application_security/index.md

@@ -116,7 +116,7 @@ The following vulnerability scanners and their databases are regularly updated:
 | [Container Scanning](container_scanning/index.md)            | A job runs on a daily basis to build new images with the latest vulnerability database updates from the upstream scanner. GitLab monitors this job through an internal alert that tells the engineering team when the database becomes more than 48 hours old. For more information, see the [Vulnerabilities database update](container_scanning/index.md#vulnerabilities-database). |
 | [Dependency Scanning](dependency_scanning/index.md)          | Relies on the [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db). It is updated on a daily basis using [data from NVD, the `ruby-advisory-db` and the GitHub Advisory Database as data sources](https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/SOURCES.md). See our [current measurement of time from CVE being issued to our product being updated](https://handbook.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) | [DAST proxy-based](dast/proxy-based.md) and [browser-based](dast/browser_based.md) engines are updated on a periodic basis. [DAST proxy-based](dast/proxy-based.md) analyzer downloads the scanning rules at scan runtime. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/main/Dockerfile#L27). [DAST browser-based](dast/browser_based.md) rules run [different vulnerability checks](dast/checks/index.md). |
-| [Secret Detection](secret_detection/index.md#detected-secrets) | GitLab maintains the [detection rules](secret_detection/index.md#detected-secrets) and [accepts community contributions](secret_detection/index.md#adding-new-patterns). The scanning engine is updated at least once per month if a relevant update is available. |
+| [Secret Detection](secret_detection/pipeline/index.md#detected-secrets) | GitLab maintains the [detection rules](secret_detection/pipeline/index.md#detected-secrets) and [accepts community contributions](secret_detection/pipeline/index.md#adding-new-patterns). The scanning engine is updated at least once per month if a relevant update is available. |
 | [Static Application Security Testing (SAST)](sast/index.md)  | The source of scan rules depends on which [analyzer](sast/analyzers.md) is used for each [supported programming language](sast/index.md#supported-languages-and-frameworks). GitLab maintains a ruleset for the Semgrep-based analyzer and updates it regularly based on internal research and user feedback. For other analyzers, the ruleset is sourced from the upstream open-source scanner. Each analyzer is updated at least once per month if a relevant update is available. |
 
 In versions of GitLab that use the same major version of the analyzer, you do not have to update
@@ -488,7 +488,7 @@ For more information about overriding security jobs, see:
 - [Overriding SAST jobs](sast/index.md#overriding-sast-jobs).
 - [Overriding Dependency Scanning jobs](dependency_scanning/index.md#overriding-dependency-scanning-jobs).
 - [Overriding Container Scanning jobs](container_scanning/index.md#overriding-the-container-scanning-template).
-- [Overriding Secret Detection jobs](secret_detection/index.md#configure-scan-settings).
+- [Overriding Secret Detection jobs](secret_detection/pipeline/index.md#configuration).
 - [Overriding DAST jobs](dast/proxy-based.md#customize-dast-settings).
 
 All the security scanning tools define their stage, so this error can occur with all of them.

doc/user/application_security/offline_deployments/index.md

@@ -93,7 +93,7 @@ above. You can find more information at each of the pages below:
 
 - [Container scanning offline directions](../container_scanning/index.md#running-container-scanning-in-an-offline-environment)
 - [SAST offline directions](../sast/index.md#running-sast-in-an-offline-environment)
-- [Secret Detection offline directions](../secret_detection/index.md#running-secret-detection-in-an-offline-environment)
+- [Secret Detection offline directions](../secret_detection/pipeline/index.md#offline-configuration)
 - [DAST offline directions](../dast/run_dast_offline.md#run-dast-in-an-offline-environment)
 - [API Fuzzing offline directions](../api_fuzzing/configuration/offline_configuration.md)
 - [License Scanning offline directions](../../compliance/license_scanning_of_cyclonedx_files/index.md#running-in-an-offline-environment)

doc/user/application_security/policies/scan-execution-policies.md

@@ -231,10 +231,10 @@ Note the following:
 - When configuring policies with a scheduled DAST scan, the author of the commit in the security
   policy project's repository must have access to the scanner and site profiles. Otherwise, the scan
   is not scheduled successfully.
-- For a secret detection scan, only rules with the default ruleset are supported. [Custom rulesets](../secret_detection/index.md#custom-rulesets)
-  are not supported. Alternatively, you may configure a [remote configuration file](../secret_detection/index.md#specify-a-remote-configuration-file) and set the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable.
-- By default, for `scheduled` scan execution policies, secret detection scans configured without any CI variables defined run first in `historic` mode (`SECRET_DETECTION_HISTORIC_SCAN` = `true`). All subsequent scheduled scans run in default mode with `SECRET_DETECTION_LOG_OPTIONS` set to the commit range between last run and current SHA. CI variables provided in the scan execution policy can override this behavior. Learn more about [historic mode](../secret_detection/index.md#full-history-secret-detection).
-- For `triggered` scan execution policies, secret detection works just like regular scan [configured manually in the `.gitlab-ci.yml`](../secret_detection/index.md#edit-the-gitlab-ciyml-file-manually).
+- For a secret detection scan, only rules with the default ruleset are supported. [Custom rulesets](../secret_detection/pipeline/index.md#custom-rulesets)
+  are not supported. Alternatively, you may configure a [remote configuration file](../secret_detection/pipeline/index.md#specify-a-remote-configuration-file) and set the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable.
+- By default, for `scheduled` scan execution policies, secret detection scans configured without any CI variables defined run first in `historic` mode (`SECRET_DETECTION_HISTORIC_SCAN` = `true`). All subsequent scheduled scans run in default mode with `SECRET_DETECTION_LOG_OPTIONS` set to the commit range between last run and current SHA. CI variables provided in the scan execution policy can override this behavior. Learn more about [historic mode](../secret_detection/pipeline/index.md#full-history-pipeline-secret-detection).
+- For `triggered` scan execution policies, secret detection works just like regular scan [configured manually in the `.gitlab-ci.yml`](../secret_detection/pipeline/index.md#edit-the-gitlab-ciyml-file-manually).
 - A container scanning scan that is configured for the `pipeline` rule type ignores the agent defined in the `agents` object. The `agents` object is only considered for `schedule` rule types.
   An agent with a name provided in the `agents` object must be created and configured for the project.
 - Variables defined in a Scan Execution Policy follow the standard [CI/CD variable precedence](../../../ci/variables/index.md#cicd-variable-precedence).

doc/user/application_security/secret_detection/pre_receive.md

 ---
-stage: Secure
-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
+redirect_to: 'pre_receive/index.md'
+remove_date: '2024-05-14'
 ---
 
-# Pre-receive secret detection
+This document was moved to [another location](pre_receive/index.md).
 
-DETAILS:
-**Tier:** Ultimate
-**Offering:** GitLab Dedicated
-**Status:** Experiment
-
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/11439) in GitLab 16.7 as an [Experiment](../../../policy/experiment-beta-support.md) for GitLab Dedicated customers.
-
-NOTE:
-This feature is an [Experiment](../../../policy/experiment-beta-support.md), available only on GitLab Dedicated, and is subject to the [GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
-
-Pre-receive secret detection scans the contents of committed files when they are pushed to a remote repository to prevent the accidental exposure of secrets like keys or API tokens to your repositories. If any secrets are detected, the push is blocked, ensuring that the secrets do not reach your instance.
-
-Pre-receive secret detection is an Experiment, and only available on GitLab Dedicated. To use secret detection in your instance, use [pipeline secret detection](../index.md) instead.
-
-## Enable pre-receive secret detection
-
-Prerequisites:
-
-- You must be an administrator for your GitLab Dedicated instance.
-
-1. Sign in to your GitLab Dedicated instance as an administrator.
-1. On the left sidebar, at the bottom, select **Admin Area**.
-1. Select **Settings > Security and Compliance**.
-1. Expand **Secret Detection**.
-1. Select the **Enable pre-receive secret detection** checkbox.
-
-## Limitations
-
-- This feature only scans non-binary blobs under 1 MiB in size. Binary blobs and blobs larger than 1 MiB are not scanned.
-- The scan does not analyze the content of a commit if it is identical to the content of another file already present in the source code.
-- The scan skips analyzing files that are renamed, deleted, or moved, unless their content is modified in the same commit.
-- The feature does not analyze files that are introduced during a repository creation.
-
-## Resolve a blocked push
-
-If the blocked secret was added with the most recent commit on your branch:
-
-1. Remove the secrets from the files.
-1. Stage the changes with `git add <file-name>`.
-1. Modify the most recent commit to include the changed files with `git commit --amend`.
-1. Push your changes with `git push`.
-
-If the blocked secret appears earlier in your Git history:
-
-1. Identify the commit SHA from the push error message. If there are multiple, find the earliest using `git log`.
-1. Use `git rebase -i <commit-sha>~1` to start an interactive rebase.
-1. Mark the offending commits for editing by changing the `pick` command to `edit` in the editor.
-1. Remove the secrets from the files.
-1. Stage the changes with `git add <file-name>`.
-1. Commit the changed files with `git commit --amend`.
-1. Continue the rebase with `git rebase --continue` until all secrets are removed.
-1. Push your changes with `git push`.
-
-## Skip secret detection
-
-In some cases, it may be necessary to skip pre-receive secret detection. For example, a developer may need to commit a placeholder secret for testing, or a user may want to bypass secret detection due to a Git operation timeout. To skip secret detection for all commits in a push, add `[skip secret detection]` to one of the commit messages. For example:
-
-```shell
-# These commits are in the same push. Both will not be scanned.
-Add real secret by accident
-Add placeholder token to test file [skip secret detection]
-```
-
-NOTE:
-[Pipeline secret detection](../index.md) still scans the bypassed secrets when using `[skip secret detection]` in one of your commit messages.
+<!-- This redirect file can be deleted after <2024-05-14>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

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

+---
+stage: Secure
+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
+---
+
+# Pre-receive secret detection
+
+DETAILS:
+**Tier:** Ultimate
+**Offering:** GitLab Dedicated
+**Status:** Experiment
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/11439) in GitLab 16.7 as an [Experiment](../../../../policy/experiment-beta-support.md) for GitLab Dedicated customers.
+
+NOTE:
+This feature is an [Experiment](../../../../policy/experiment-beta-support.md), available only on GitLab Dedicated, and is subject to the [GitLab Testing Agreement](https://handbook.gitlab.com/handbook/legal/testing-agreement/).
+
+Pre-receive secret detection scans the contents of committed files when they are pushed to a remote repository to prevent the accidental exposure of secrets like keys or API tokens to your repositories. If any secrets are detected, the push is blocked, ensuring that the secrets do not reach your instance.
+
+Pre-receive secret detection is an Experiment, and only available on GitLab Dedicated. To use secret detection in your instance, use [pipeline secret detection](../index.md) instead.
+
+## Enable pre-receive secret detection
+
+Prerequisites:
+
+- You must be an administrator for your GitLab Dedicated instance.
+
+1. Sign in to your GitLab Dedicated instance as an administrator.
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. Select **Settings > Security and Compliance**.
+1. Expand **Secret Detection**.
+1. Select the **Enable pre-receive secret detection** checkbox.
+
+## Limitations
+
+- This feature only scans non-binary blobs under 1 MiB in size. Binary blobs and blobs larger than 1 MiB are not scanned.
+- The scan does not analyze the content of a commit if it is identical to the content of another file already present in the source code.
+- The scan skips analyzing files that are renamed, deleted, or moved, unless their content is modified in the same commit.
+- The feature does not analyze files that are introduced during a repository creation.
+
+## Resolve a blocked push
+
+If the blocked secret was added with the most recent commit on your branch:
+
+1. Remove the secrets from the files.
+1. Stage the changes with `git add <file-name>`.
+1. Modify the most recent commit to include the changed files with `git commit --amend`.
+1. Push your changes with `git push`.
+
+If the blocked secret appears earlier in your Git history:
+
+1. Identify the commit SHA from the push error message. If there are multiple, find the earliest using `git log`.
+1. Use `git rebase -i <commit-sha>~1` to start an interactive rebase.
+1. Mark the offending commits for editing by changing the `pick` command to `edit` in the editor.
+1. Remove the secrets from the files.
+1. Stage the changes with `git add <file-name>`.
+1. Commit the changed files with `git commit --amend`.
+1. Continue the rebase with `git rebase --continue` until all secrets are removed.
+1. Push your changes with `git push`.
+
+## Skip secret detection
+
+In some cases, it may be necessary to skip pre-receive secret detection. For example, a developer may need to commit a placeholder secret for testing, or a user may want to bypass secret detection due to a Git operation timeout. To skip secret detection for all commits in a push, add `[skip secret detection]` to one of the commit messages. For example:
+
+```shell
+# These commits are in the same push. Both will not be scanned.
+Add real secret by accident
+Add placeholder token to test file [skip secret detection]
+```
+
+NOTE:
+[Pipeline secret detection](../index.md) still scans the bypassed secrets when using `[skip secret detection]` in one of your commit messages.

ee/app/assets/javascripts/vue_shared/showcase/card_security_showcase_app.vue

@@ -24,9 +24,12 @@ export default {
   sastHelpPage: helpPagePath('user/application_security/sast/index.md', {
     anchor: 'configuration',
   }),
-  secretDetectionHelpPage: helpPagePath('user/application_security/secret_detection/index.md', {
-    anchor: 'configuration',
-  }),
+  secretDetectionHelpPage: helpPagePath(
+    'user/application_security/secret_detection/pipeline/index.md',
+    {
+      anchor: 'configuration',
+    },
+  ),
 };
 </script>
 

ee/spec/frontend/vue_shared/showcase/__snapshots__/card_security_showcase_app_spec.js.snap

@@ -38,7 +38,7 @@ exports[`Card Security Showcase App renders correctly 1`] = `
     <card-showcase-stub
       description="Scan your code to detect unintentionally committed secrets, like keys, passwords, and API tokens."
       primaryaction="Enable Secret Detection"
-      primarylink="/help/user/application_security/secret_detection/index.md#configuration"
+      primarylink="/help/user/application_security/secret_detection/pipeline/index.md#configuration"
       primarylinkicon="external-link"
       primarytrackinglabel="enable_secret_detection"
       primarytrackingproperty=""

lib/gitlab/security/features.rb

@@ -71,11 +71,11 @@ def self.data
           },
           secret_detection: {
             name: _('Secret Detection'),
-            description: _('Analyze your source code and git history for secrets.'),
+            description: _('Analyze your source code and Git history for secrets.'),
             help_path: Gitlab::Routing.url_helpers.help_page_path(
-              'user/application_security/secret_detection/index'),
+              'user/application_security/secret_detection/pipeline/index'),
             configuration_help_path: Gitlab::Routing.url_helpers.help_page_path(
-              'user/application_security/secret_detection/index', anchor: 'configuration'),
+              'user/application_security/secret_detection/pipeline/index', anchor: 'configuration'),
             type: 'secret_detection'
           },
           api_fuzzing: {

lib/security/ci_configuration/base_build_action.rb

@@ -41,7 +41,7 @@ def comment
         <<~YAML
           # You can override the included template(s) by including variable overrides
           # SAST customization: https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings
-          # Secret Detection customization: https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings
+          # Secret Detection customization: https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customization
           # Dependency Scanning customization: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-the-dependency-scanning-settings
           # Container Scanning customization: https://docs.gitlab.com/ee/user/application_security/container_scanning/#customizing-the-container-scanning-settings
           # Note that environment variables can be set in several places

locale/am_ET/gitlab.po

@@ -13160,7 +13160,7 @@ msgstr ""
 msgid "Configure SAST in `.gitlab-ci.yml`, creating this file if it does not already exist"
 msgstr ""
-msgid "Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings) to customize Secret Detection settings."
+msgid "Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customization) to customize Secret Detection settings."
 msgstr ""
 msgid "Configure Secret Detection in `.gitlab-ci.yml`, creating this file if it does not already exist"

locale/ar_SA/gitlab.po

@@ -13876,7 +13876,7 @@ msgstr ""
 msgid "Configure SAST in `.gitlab-ci.yml`, creating this file if it does not already exist"
 msgstr ""
-msgid "Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings) to customize Secret Detection settings."
+msgid "Configure Secret Detection in `.gitlab-ci.yml` using the GitLab managed template. You can [add variable overrides](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customization) to customize Secret Detection settings."
 msgstr ""
 msgid "Configure Secret Detection in `.gitlab-ci.yml`, creating this file if it does not already exist"