Add latest changes from gitlab-org/gitlab@master

3 files changed, 93 insertions, 5 deletions

diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md
index ddf8db4e489..f0af7e00af5 100644
--- a/doc/user/application_security/sast/customize_rulesets.md
+++ b/doc/user/application_security/sast/customize_rulesets.md
@@ -79,6 +79,37 @@ To create the ruleset configuration file:
 1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
 1. Create a file named `sast-ruleset.toml` in the `.gitlab` directory.
 
+## Specify a remote configuration file
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393452) in 16.0.
+
+You can set a [CI/CD variable](../../../ci/variables/index.md) to use a ruleset configuration file that's stored outside of the current repository.
+This can help you apply the same rules across multiple projects.
+
+The `SAST_RULESET_GIT_REFERENCE` variable uses a format similar to
+[Git URLs](https://git-scm.com/docs/git-clone#_git_urls) for specifying a project URI,
+optional authentication, and optional Git SHA. The variable uses the following format:
+
+```plaintext
+[<AUTH_USER>[:<AUTH_PASSWORD>]@]<PROJECT_PATH>[@<GIT_SHA>]
+```
+
+NOTE:
+If a project has a `.gitlab/sast-ruleset.toml` file committed, that local configuration takes precedence and the file from `SAST_RULESET_GIT_REFERENCE` isn't used.
+
+The following example [enables SAST](index.md#configure-sast-in-your-cicd-yaml) and uses a shared ruleset customization file.
+In this example, the file is committed on the default branch of `example-ruleset-project` at the path `.gitlab/sast-ruleset.toml`.
+
+```yaml
+include:
+  - template: Jobs/SAST.gitlab-ci.yml
+
+variables:
+  SAST_RULESET_GIT_REFERENCE: "gitlab.com/example-group/example-ruleset-project"
+```
+
+See [specify a private remote configuration example](#specify-a-private-remote-configuration) for advanced usage.
+
 ## Schema
 
 ### The top-level section
@@ -352,23 +383,23 @@ The syntax used for the `value` follows the [njsscan config format](https://gith
 ---
 - nodejs-extensions:
   - .js
-  
+
   template-extensions:
   - .new
   - .hbs
   - ''
-  
+
   ignore-filenames:
   - skip.js
-  
+
   ignore-paths:
   - __MACOSX
   - skip_dir
   - node_modules
-  
+
   ignore-extensions:
   - .hbs
-  
+
   ignore-rules:
   - regex_injection_dos
   - pug_jade_template
@@ -560,3 +591,20 @@ rules:
   languages:
     - "go"
 ```
+
+### Specify a private remote configuration
+
+The following example [enables SAST](index.md#configure-sast-in-your-cicd-yaml) and uses a shared ruleset customization file. The file is:
+
+- Downloaded from a private project that requires authentication, by using a [Group Access Token](../../group/settings/group_access_tokens.md).
+- Checked out at a specific Git commit SHA instead of the default branch.
+
+See [group access tokens](../../group/settings/group_access_tokens.md#bot-users-for-groups) for how to find the username associated with a group token.
+
+```yaml
+include:
+  - template: Security/SAST.gitlab-ci.yml
+
+variables:
+  SAST_RULESET_GIT_REFERENCE: "group_2504721_bot_7c9311ffb83f2850e794d478ccee36f5:glpat-1234567@gitlab.com/example-group/example-ruleset-project@c8ea7e3ff126987fb4819cc35f2310755511c2ab"
+```
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index 293441ed084..1f07e9a5eb7 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -495,6 +495,36 @@ path = "/gitleaks.toml"
   ]
 ```
 
+## Specify a remote configuration file
+
+Projects can be configured with a [CI/CD variable](../../../ci/variables/index.md) in order
+to specify a ruleset configuration outside of the current repository.
+
+The `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable uses an SCP-style syntax for specifying a URI,
+optional authentication, and optional Git SHA. The variable uses the following format:
+
+```plaintext
+<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>
+```
+
+NOTE:
+Loading local project configuration takes precedence over `SECRET_DETECTION_RULESET_GIT_REFERENCE` values.
+
+The following example includes the Secret Detection template in a project to be scanned and specifies
+the `SECRET_DETECTION_RULESET_GIT_REFERENCE` variable for referencing a separate project configuration.
+
+```yaml
+include:
+  - template: Jobs/Secret-Detection.gitlab-ci.yml
+
+variables:
+  SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/example-ruleset-project"
+```
+
+For more information on the syntax of remote configurations, see the
+[specify a private remote configuration example](../sast/customize_rulesets.md#specify-a-private-remote-configuration)
+on the SAST customize rulesets page.
+
 ## Running Secret Detection in an offline environment **(PREMIUM SELF)**
 
 An offline environment has limited, restricted, or intermittent access to external resources through
diff --git a/doc/user/compliance/license_approval_policies.md b/doc/user/compliance/license_approval_policies.md
index 860c2008021..82830c4e1ff 100644
--- a/doc/user/compliance/license_approval_policies.md
+++ b/doc/user/compliance/license_approval_policies.md
@@ -24,6 +24,16 @@ The following video provides an overview of these policies.
   <iframe src="https://www.youtube-nocookie.com/embed/34qBQ9t8qO8" frameborder="0" allowfullscreen> </iframe>
 </figure>
 
+## Prerequisites to creating a new license approval policy
+
+License approval policies rely on the output of a dependency scanning job to verify that requirements have been met. If dependency scanning has not been properly configured, and therefore no dependency scanning jobs ran related to an open MR, the policy has no data with which to verify the requirements. When security policies are missing data for evaluation, they fail closed and assume the merge request could contain vulnerabilities.
+
+To ensure enforcement of your policies, you should enable dependency scanning on your target development projects. You can achieve this a few different ways:
+
+- Create a global [scan execution policy](../application_security/policies/scan-execution-policies.md) that enforces Dependency Scanning to run in all target development projects.
+- Use a [Compliance Pipeline](../../user/group/compliance_frameworks.md#compliance-frameworks) to define a Dependency Scanning job that is enforced on projects enforced by a given Compliance Framework.
+- Work with development teams to configure [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) in each of their project's `.gitlab-ci.yml` files or enable by using the [Security Configuration panel](../application_security/configuration/index.md).
+
 ## Create a new license approval policy
 
 Create a license approval policy to enforce license compliance.